Requirements and Safeguards for ECommerce

2. Requirements and Safeguards for ECommerce • Entity authentication • Message integrity • Payment non-repudiation • Effective audit mechanism • Privacy

3. POLICY

5. http://www.fish.com/security/murphy.html ALL: .bad.domain: finger -l @%h |\ /usr/ucb/mail root

6. Basics • Kernel based systems (Unix, Linux)vs • Microkernel based systems (Win2k, GNU HURD) • Mandatory access control (common criteria) http://www.radium.ncsc.mil/tpep/library/fers/index.html

7. UID 0 • GID 0 • Processes • Threads

8. Typical attributes associated with each process in a Unix-like system: • RUID, RGID • real UID and GID of the user on whose behalf the process is running · • EUID, EGID • effective UID and GID used for privilege checks (except for the filesystem) · • SUID, SGID • Saved UID and GID; used to support switching permissions ``on and off''

9. setuid or setgid files • May cause race conditions • Setuid scripts (#!/bin/sh) • Open setuid script and Find needed interpreter • Run it and set its uid • It reopens the script to run it • ?? • Linux?

10. Files • The root or / • File systems: FAT, NTFS, EXT2, ..etc • FSOs • ordinary files • directories, • symbolic links, • named pipes (also called first-in first-outs or FIFOs), • Sockets • character special (device) files • block special

11. Most filesystems on Unix-like systems store at least the following: • owning UID and GID - identifies the ``owner'' of the filesystem object • permission bits - read, write, execute bits for each of user (owner), group, and other. · • ``sticky'' bit • setuid, setgid - when set on an executable file, executing the file will set the process' effective UID oreffective GID to the value of the file's owning UID or GID (respectively) • timestamps

12. Creation Time Initial Values • Changing Access Control Attributes • Using Access Control Attributes • Filesystem Hierarchy • http://www.pathname.com/fhs

13. Sockets and Network Connections • creates an endpoint for communication and returns a descriptor • The parameters for socket specify the protocol family and type (e.g., TCP/IP, Novell's IPX, …) • A server Application typically calls • bind(2) • listen(2), • accept(2) • select(2) • A client typically calls • bind(2) • connect(2)

14. Links • http://www.lowtek.com/sockets/ • http://www.ibrado.com/sock-faq/ • http://tangentsoft.net/wskfaq/

15. Signals • Signals are a simple form of ``interruption'' • A process can set a ``signal'' on another process (say using kill(1) or kill(2)), and that other process would receive and handle the signal asynchronously. • To send an arbitrary signal to other process, the sending process must either have: • root privileges, or • the real or effective user ID of the sending process must equal the real or saved set-user-ID of the receiving process • some signals can be sent in other ways • SIGURG can be delivered over a network through the TCP/IP out-of-band (OOB) message.

16. Where possible, have your signal handlers unconditionally set a specific flag and do nothing else If you must have more complex signal handlers, use only calls specifically designated as being safe for use in signal handlers. • In particular, don't use malloc() or free() in C (which on most systems aren't protected against signals), nor the many functions that depend on them (such as the printf() family and syslog()). You could try to ``wrap'' calls to insecure library calls with a check to a global flag (to avoid re-entry), but I wouldn't recommend it. • Block signal delivery during all non-atomic operations in the program, and block signal delivery inside signal handlers.

17. Quotas and Limits • support filesystem quotas and process resource limits • ``hard'' vs. ``soft'' limits • A ``hard'' filesystem quota limit is a never-to-exceed limit, while a ``soft'' quota can be temporarily exceeded • See quota(1), quotactl(2), and quotaon(8). • rlimit mechanism process quotas: • file size, • number of child processes, • number of open files, and so on. • ``soft'' limit (also called the current limit) and a ``hard limit'' (also called the upper limit). The soft limit cannot be exceeded at any time, but through calls it can be raised up to the value of the hard limit • See getrlimit(2), setrlimit(2), and getrusage(2), sysconf(3), and ulimit(1).

18. Dynamically Linked Libraries • /etc/ld.so.conf • Various environment variables can control the process of loading DLLs • Permitting user control over DLLs could lead to interesting effects for setuid/setgid programs! • http://www.dwheeler.com/program-library/

19. Audit • Different Unix-like systems handle auditing differently. In Linux, the most common ``audit'' mechanisms are: • syslogd(8) • klogd(8) • wtmp(5) and utmp(5) • lastlog(8) • acct(2) • server programs (such as the Apache web server) also have their own audit trail (see /var/log)

20. PAM • Pluggable Authentication Modules (PAM) • PAM permits run-time configuration of authentication methods (e.g., use of passwords, smart cards, etc.)

21. Specialized Security Extensions for Unix-like Systems • Jail • http://docs.freebsd.org/44doc/papers/jail/jail.html • Security-Enhanced Linux • http://www.nsa.gov/selinux/ • Rule Set Based Access Control (RSBAC) for Linux • http://www.rsbac.de/ • Pluggable linux security module framework • http://mail.wirex.com/mailman/listinfo/linux-security-module • ... etc.

22. Security Requirements `Do you mean that you think you can find out the answer to it?' said the March Hare. `Exactly so,' said Alice. `Then you should say what you mean,' the March Hare went on. `I do,' Alice hastily replied; `at least--at least I mean what I say--that's the same thing, you know.' `Not the same thing a bit!' said the Hatter. `You might just as well say that "I see what I eat" is the same thing as "I eat what I see"!' `You might just as well say,' added the March Hare, `that "I like what I get" is the same thing as "I get what I like"!' `You might just as well say,' added the Dormouse, who seemed to be talking in his sleep, `that "I breathe when I sleep" is the same thing as "I sleep when I breathe"!' `It IS the same thing with you,' said the Hatter, and here the conversation dropped, and the party sat silent for a minute, while Alice thought over all she could remember about ravens and writing-desks, which wasn't much.

23. Security Requirements • “Before you can determine if a program is secure, you need to determine exactly what its security requirements are.” • the Common Criteria, standardized as ISO/IEC 15408:1999. • The Common Criteria for Information Technology Security Evaluation (CC). August 1999. • Version 2.1. Technically identical to International Standard ISO/IEC 15408:1999. • http://csrc.nist.gov/cc/ccv20/ccv2list.htm

24. The Common Criteria for Information Technology Security Evaluation • The CC document has three parts: • the introduction (that describes the CC overall), • security functional requirements (that lists various kinds of security functions that products might want to include), and • security assurance requirements (that lists various methods of assuring that a product is secure). • the "Common Evaluation Methodology" (CEM) • guides evaluators on how to apply the CC when doing formal evaluations

25. The CC is typically used to create two kinds of documents: • a ``Protection Profile'' (PP) or • a ``Security Target'' (ST).

26. To create a PP or ST • go through a process of identifying • the security environment, • Your assumptions, • threats, and • relevant organizational security policies. • Two kinds of security requirements: • Functional requirements (what a product has to be able to do), and • Assurance requirements (measures to inspire confidence that the objectives have been met).

27. EALs • Pre-created sets of assurance requirements called ``evaluation assurance levels'' (EALs) • EAL 1 to 7

28. Security Environment and Objectives • Consider: • the physical environment (can attackers access the computer hardware?), • the assets requiring protection (files, databases, authorization credentials, and so on), and • the purpose of the system (what kind of product is it? what is the intended use?)

29. Security Functionality Requirements • the major classes of CC security requirements • Security Audit (FAU) • Communication/Non-repudiation (FCO) • Cryptographic Support (FCS) • User Data Protection (FDP) • access control or information flow rules, • develop various means to implement the policy, • possibly support off-line storage, • import, and export, and provide integrity when transferring user data

30. Identification and authentication (FIA) • Security Management (FMT) • Privacy (FPR) • Protection of the TOE Security Functions/Self-protection (FPT) • Resource Utilization (FRU) • TOE Access (FTA). • controlling sessions (concurrency, locking, ..etc). • Trusted path/channels (FTP)

31. Security Assurance Measure Requirements • Configuration management (ACM) • Delivery and operation (ADO) • Development (ADV) • Guidance documents (AGD) • Life-cycle support (ALC) • Tests (ATE) • Vulnerability Assessment (AVA) • Maintenance of assurance (AMA)

32. Input Validation • Determine what is legal and reject anything that does not match that definition. • Do not do the reverse: • identify what is illegal and write code to reject those cases • Use “illegal” values as a set of tests to be sure that your validation code is thorough

33. Examples: • For strings, identify the legal characters or legal patterns (e.g., as a regular expression) and reject anything not matching that form. There are special problems when strings contain control characters (especially linefeed or NIL) or metacharacters (especially shell metacharacters); it is often best to ``escape'' such metacharacters immediately • Limit all numbers to the minimum (often zero) and maximum allowed values. • email address (checker is actually quite complicated, because there are legacy formats that complicate validation) • Filenames • URIs • Also remember to decode any encoding first (IIS) • Cross site scripting

34. Cookies • Delimiters • Special character /scripts/../../../winnt/system32/cmd.exe?/c+dir /scripts/..%255c..%255c../winnt/system32/cmd.exe?/c+dir

35. Command line • A setuid/setgid program's command line data is provided by an untrusted user! • must not trust the name of the program reported by command line argument zero

36. Environment Variables • By default, environment variables are inherited from a process' parent. • The calling program can set the environment variables to arbitrary values. • setuid/setgid invoker can completely control the environment variables

37. Some Environment Variables are Dangerous • For example • the IFS variable is used by sh and bash to determine which characters separate command line arguments • /bin/sh vs • bin sh

38. Environment Variable Storage Format is Dangerous • environment variables are internally stored as a pointer to an array of pointers to characters; this array is stored in order and terminated by a NULL pointer • The pointers to characters each point to a NIL-terminated string value of the form “NAME=value” • environment variable names can't include the equal sign • neither the name nor value can have embedded NIL characters. • allows multiple entries with the same variable name with different values (e.g., more than one value for SHELL) • Don’t manipulate environment variable yourself use glibc instead

39. The Solution - Extract and Erase • Extract the variables you need • Erase the entire environment space • If needed set the environment values once more • environ = NULL; • clearenv();

40. File Descriptors • Suid and standard input, output and error

41. File Names • .. • \/ • globbing • ftp> ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../* • BO using globbing?! • rm –f/

42. File Contents • 0x90 0x90 …etc.

43. Web-Based Application Inputs • %HH encoding • %2500 => %00 => NULL • http://victim.com/defualt.asp%00 • Cookie values • Other http header fields • Performing client side checking and forgetting server side checking!

44. Locales and i18n • Locale information provided by Environment variable • catgets, catopen, gettext • NLSPATH

45. Buffer overflows

46. Structure Program Internals andApproach • Follow Good Software Engineering Principles for Secure Programs • Least privilege. • Economy of mechanism/Simplicity. • Open design. • Complete mediation. • Fail−safe defaults (e.g., permission−based approach). • Separation of privilege. • Least common mechanism. • Psychological acceptability / Easy to use.

47. Secure the Interface • Interfaces should be: • minimal (simple as possible) • narrow (provide only the functions needed) • non−bypassable • Trust should be minimized • Consider limiting the data that the user can see

48. Separate Data and Control • Any files you support should be designed to completely separate (passive) data from programs that are executed • Don’t include scripts or macros • Especially auto-executing macros • I you have to violate the above make sure the scripts run in a good sandbox! • Have the dynamic parts stored separately from the static parts (e.g., separate file), so that it's easier to block them out when needed

49. From: http://www.cl.cam.ac.uk/~rja14/ I don't execute programs sent to me by strangers unless I have good reason, and then only after appropriate precautions. This means, in particular, that I don't read attachments in formats such as Microsoft Word, unless by prior arrangement. I also discard html-format emails unread, as the vast majority of them are spam. If you're trying to contact me from a hotmail account and don't get an answer, this may be the reason.

50. Minimize Privileges • Minimize the Privileges Granted • For example: create a special group, change a file's group ownership to that group, and then make the program setgid to that group • consider creating a new pseudouser or pseudogroup • For example: web servers typically need root privileges to start up (to use port 80), but once started they usually shed all their privileges and run as the user “nobody” • If a process must run as root consider using POSIX capabilities