[soen321-f04] material for second lecture (Sep 13)[soen321-f04] material for second lecture (Sep 13) David K. Probst PROBST at vax2.concordia.ca Mon Sep 13 21:43:39 EDT 2004 Previous message: [soen321-f04] building secure software (formatted) Next message: [soen321-f04] Fw: US-CERT Technical Cyber Security Alert TA04-260A -- Microsoft Windows JPEG component buffer overflow Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] SOEN 321 Week 2 Lecture Material _________________________________ Three very important points to remember are: Lemma 1. The bulk of computer insecurity is due to the exploitation of, i.e., attacks applying skillful pressure to, bugs, which are errors or weaknesses in the design, implementation, or operation of a computer system. Corollary. The most serious flaws are those that are extremely well hidden. Our complexity-management strategies break regularly, leaving inherent weaknesses in the technology that are simply beyond human intellect to recognize. Lemma 2. Computer security becomes vastly more difficult with either increased system scale/complexity or increased richness of system connectivity or both. Lemma 3. The correctness of a security system is a function of the assumed trust model. How are security measures implemented? - in the old days, controlling physical access to the computer was both necessary and sufficient; now, controlling physical access to some parts of the computer system is necessary but not sufficient - with multiprogramming, we need to add OS protection - with networking, we need to add a whole new set of security mechanisms Technical solutions must be embedded in a wider context of physical and legal controls, and personnel assurance. In computer security, both system and human vulnerabilities must be properly emphasized. Here are two definitions that complement a few we saw in Week 1: Computer security: Techniques for computing in the presence of adversaries. Cryptography: Techniques for communicating in the presence of adversaries. Protection and OS Security __________________________ Protection: The subset of computer security that deals with controlling access to information and computing resources stored locally. Traditionally, this excludes issues arising from networks. Protection includes operating-system mechanisms for controlling access to local information and resources. Protection also deals with: - confidentiality: preventing unauthorized release of information or resources - integrity: preventing unauthorized modification of information or resources - availability: preventing denial-of-service attacks - accountability: holding users accountable for their system actions Protection provides all of this in the context of a single machine. We will look at two subproblems: - access control: enforcement of restrictions on who may access what - security-policy selection: a human-level statement of goals for the security system The access-control problem is to decide whether a given request should be granted. There are two steps: - authenticate: verify the identity of the entity making the request - authorize: verify that the access-control policy allows the request A security policy is a specification of the desired security properties of the system. It lays out goals that the security mechanisms are intended to achieve. Computer-security policies should roughly correspond---whenever possible---to real-world policies. Example: Just as two bank officers may be required to authorize the opening of a bank vault, so the computational ability to run some sensitive program may be distributed between two partly trusted users of a computer system. The two users have to combine their partial computational abilities _each time_ they want to run the program. This is partial and distributed trust. Unix is a system without checks and balances; it is no longer appropriate to modern security needs. It has the concept of 'root', which confers too much privilege on single entities. No thought is given to the question: "How can we arrange society so that our rulers do not do us too much harm?". Total power is vested in the sysadmin and in privileged processes. There are no intermediate privilege levels. Trust is binary: neither partial nor distributed. Aside from the 'setuid' system call, processes cannot re-authenticate and change authorization; there is no smooth way to dynamically alter a process' protection domain. Resources are not active and cannot engage in authentication or authorization activity with clients. The name space of the file system is global, which interferes with confinement. In more modern computers, the Unix naming mechanism (through the 'uid' of processes) is outmoded. Subjects and Objects ____________________ Think about access control in terms of subjects (principals) and objects. A subject is an entity (executing program, user, in Unix-speak, a 'uid') making a request. An object is an item (memory word, file, printer, etc.) to which access is requested. Any policy specification can be translated into an _access-control matrix_, where subjects index rows and objects index columns. The matrix entry specifies whether S may access O. Abstractly, access control is two steps: - authenticate: identify the subject making the request - authorize: perform a table lookup to check a matrix entry We actually want more fine-grained controls so matrix entries are sets of permissions. For each type, there is a global set of _permissions_ (read, write, execute, etc.). The matrix entry contains the subset of permissions that S has to access O. This is convenient for analysis. Given two distinct subjects S and S', suppose we wish to determine whether S may send a message to S'. Here, we simply search for all objects O to which S has write permission, and then check if S' has read permission to any of them. Discretionary and Mandatory Access Controls ___________________________________________ DAC: the owner of each object gets to set the permissions of the object MAC: the sysadmin gets some control over the acess controls of every object DAC is also called _identity-based access_, while MAC is also called _rule-based access_. The MAC style comes from the military. Example: Anything marked "classified" may not be sent to a printer in an unclassified facility. Objects are such things as pages of memory, files on a storage device, I/O devices, and communication channels to other subjects. Access-Control Lists ____________________ One typical way to implement access control is via _access-control lists_, or ACLs. Here, each object O is tagged with an ACL. The ACL contains the list of subjects S who may access object O. Example: allow read, write Alice, Jim [for some object O] allow read John, Jim, Bob allow delete Alice deny read Eric Capabilities ____________ Capability: An unforgeable "ticket" whose possession presents proof that the holder is authorized to access the specified object in the specified way. Example: Permissions may be further restricted, e.g., by including an expiration date. Nowadays, it is common that these are enforced in the OS: the OS keeps track of all your capabilities for you, and manipulating them requires a system call. There are pointer solutions: a capability is a pointer to the object in question, and capabilities are sparse in the potential name space. There are cryptographic solutions: a capability is a ticket encrypted under a key only the OS knows. Performance ___________ With ACLs, access-control decisions are made at the time of each access request. With capabilities, access-control decisions are made once when the capability is granted. Thus, capabilities potentially allow much higher performance by caching access-control decisions. With ACLs, sharing is quite restricted (usually). With capabilities, sharing is freely allowed (usually). With ACLs, revocation is straightforward. With capabilities, revocation is nearly impossible (although expiration dates help). But what is the _dynamic_ behavior of the access-control system? Hybrid Approach _______________ When an ACL is too slow, inflexible, or unwieldy, first grant access to a capability by checking and ACL, and then grant access to the object according to the capability. For example, in Unix, when you open() a file, it checks the file's ACL. The open() command returns an active file descriptor, which is just a capability to access the file. Can this file descriptor be passed around at will? The descriptor is stored in the kernel's address space, which is outside the program's address space. Only if there is a system call to move the actual file descriptor to the kernel space of another process could the process transfer it to some other process. The streams calls are an example. Address Spaces ______________ Memory protection in Unix is a nice collaboration between the hardware and the operating system. Later, we will see that, in similar fashion, kernel mode enforces 'superuser' status. The element of protection is a memory page. Enforcement is the joint result of the OS kernel and the hardware memory-management subsystem. We use virtual memory for protection: authorization to access a page is checked by the OS when you load a page of memory into your virtual address space, and hardware then ensures that memory accesses are restricted to valid pages, i.e., pages in your page table. You can think of the virtual-memory map loaded into the hardware as a set of capabilities granting access to physical memory; the OS kernel enforces an ACL on physical pages of memory. Alteration of Protection Domain _______________________________ Enforcing access control on a static system with an unchanging access-control policy (constant value of the access-control matrix) is "easy". The problem becomes much harder when you introduce _dynamics_, i.e., the ability to modify policy while the system is running. A useful permission (just like read, write, etc.) in this context is the permission to modify the ACL for the object in question. This makes the system more difficult to analyze. For example, suppose we wish to determine whether subject S can modify object O. It is not enough to check whether S has write permission to O. One must also check whether S has permission to modify the permissions for O, or whether S can modify anything which can modify O, etc. Authentication ______________ Authentication is verifying the claim of identity of an entity (possibly a person) that initiated a given request. For people, here are some relevant attributes: - something you know: passwords, cryptographic keys - something you have: hardware tokens - something you are: biometrics (fingerprints, iris scans, palm prints, hand geometry, typing rates, gait, etc.) The sensible approach is to use several attributes in common. In password authentication, the system stores the result of "hashing" the password (the transformation cannot really be inverted but it can be subverted by off-line dictionary attack or even on-line guessing). The login request is validated by "hashing" the password that has been supplied and comparing it to the stored "hash" value. Unix Passwords ______________ When the account is created, or when a user changes his password, we apply a one-way (i.e., non-invertible) hash function and store the result. Since we are hashing into a space of equal cardinality, the probabilistic collision-detection algorithms have no force. Only dictionary attack is possible, but dictionary attacks work great. The reason is that a large subset of the "domain" of the hash function can be articulated explicitly. The hash function is called "crypt()". It is based on DES. Crypt() takes the user's password as the DES encryption key and encrypts zero, iteratively. The final 64-bit result is unpacked into 11 characters (we started with 8 characters or 56 bits). The idea of using salt comes from Robert Morris, Sr. The salt is randomly chosen per hash instance. The salt does not make it harder to guess any one password, but it makes it harder to run a dictinary attack against a group of users. Still, all this is silly: hide the password file and don't use passwords in the first place. To understand the salt, remember that there are pre-defined tables in the DES encryption algorithm. By changing the tables, we get a different algorithm. The salt, which is remembered in the password file, selects one out of 4,096 slightly different DES encryption algorithms. Re-Usable Passwords Are Not Good ________________________________ - guessability: most people pick poor passwords (e.g., dictionary attacks) - eavesdropping: in protocols like 'telnet', 'ftp', etc., passwords are sent in the clear over the network where they may be intercepted For authentication across a network, passwords are obsolete technology. They must be replaced by cyptographic strong authentication. Enforcement ___________ How is access control enforced? - hardware - operating-system kernel - trusted subsystems In practice, hardware provides very simple mechanisms, which are used to bootstrap an OS kernel. Then, the security mechanism is refined by trusted programs run under the OS. Hardware Modes ______________ The concept of privileged execution states is critical. - two hardware execution modes, _supervisor_ (or _privileged_) mode and _user_ (or _unprivileged_ mode) - privileged instructions (memory mapping, I/O, etc.) can only be executed in supervisor mode - OS kernel runs in supervisor mode; normal programs run in user mode - a program running in _user_ mode may only switch to _privileged_ mode by way of predefined gates (e.g., a system call) which contain special checks and guards A (good) refinement of this approach is _rings_, where there are multiple levels of privilege. Upgrading Privileges ____________________ How does a call to a privileged-mode routine work? - trap to operating system - operating system checks arguments Be careful with call-by-reference arguments and return addresses! - OS executes privileged system-call code - system returns original process to user mode More Unix _________ The super user. Every user has a username and a single number, the uid. Some other usernames are: root, , nobody. Uid 0 is root ("superuser"). Root is sort of the identity of the OS itself. We have groups. E.g., professors are in the group 'faculty'. The root account is not the sysadmin's personal account, but the sysadmin will 'su' from time to time to create a new process running in a privileged shell. Any process that has an _effective_ uid of zero runs as the superuser. Associated with the same process are both a real and an effective uid, normally the same. Sometimes one needs to change one's userid temporarily. The 'su' program is provided for this purpose. If I type 'su' (i.e., su root), then I must supply the root password. Some flavors of Unix have wheelgroups so that not anyone can do this. There are also setuid programs, including setuid-root programs. Suppose you are a normal process and you would like to execute a single command with root privileges. Login as root is most inappropriate. Instead, Unix uses setuid files. When an suid file is run, the original process takes on the _effective_ uid of the owner of the file. Simple example: Consider the /etc/password file. It is not writable by us, yet we can change our passwords. The 'passwd' program file's suid bit is set. This program is owned by root. When a user runs 'passwd', his effective uid becomes 0---as long as 'passwd' is running. Any file that is owned by root and has its suid bit set is a potential security hole. This is especially true if the file is a shell script. If an attacker can find a way to exit the shell before the shell terminates, he will then be root. Hence: - use suid programs sparingly - use suid-root programs super sparingly - never create suid-root shell scripts Important Reminders ___________________ Code always runs as part of some process, which is its protection domain. If you are running in unprivileged mode, you can only switch to privileged mode by predefined gates (e.g., a system call) which contain special checks and guards. The most important file attributes for us are file permissions and the file owner. We have seen that the "execute bit" sometimes is a setuid bit. Unix privilege levels _____________________ user, account, username, userid system usernames (root), system userids Unix privileges defined by uid (and sometimes gid) root, i.e., uid = 0, is a superuser groups superuser: unrestricted privilege; can be used by sysadmin to perform special tasks the 'su' command spawns a shell a process can have an effective uid of 0 example of privileged syscall: chroot () the /etc/passwd file; entry = traditionally, a 13-character "phash"; newer Linux's differ shadow password file; interaction with NFS users and groups, root (the superuser); uid is what counts the superuser exerts nearly complete control over the operating system principle of least privilege, compartments, "need to know" su ("set user") command, su root; superuser has distinct prompt processes, command interpreters, real and effective uids suid bits in access-control lists; suid files; suid-root files on having your own process's privilege raised in a controlled way and why this is dangerous example: 'passwd' Why networks change things __________________________ Start with LANs. All kinds of silly practices began to flourish. I want to log on to a new host on the LAN, but I am too lazy to re-enter my password. In the past, on some flavors of Unix, two very dangerous files were likely to exist. The /etc/hosts.equiv file: Any host listed here is considered trusted. If your username is the same on two trusted hosts, you can 'rlogin' or 'rsh' from one to another without typing a password. There is no fault isolation. Worse, in your home directory, you might have a '.rhosts' file, a set of trusted hosts applicable only to you. You can 'rlogin' between two of your trusted hosts without using a password. Many older SunOS systems were shipped with: hosts.equiv containing: + !! 'rsh' is like 'rlogin' except that instead of logging in, you simply run a single command on the remote system. There are countless problems with these schemes, starting with using IP addresses for authentication. What about Internet services? You should seriously consider disabling 'finger', 'systat', and 'tftp'. The former three reveal much information about your system; the fourth is totally insecure. [number?] What do networks change the protection problem? - remote virtual terminals (telnet and rlogin) - e-mail - electronic directory service (finger, whois, ph) - date and time - remote procedure call - Internet services (exec, login, print, X-windows) Vulnerabilities include: - network sniffers - IP spoofing - connection hijacking - data spoofing Bellovin's Three Firewall Theorems __________________________________ Axiom 1 ("Murphy"): All programs are buggy. Theorem 1 (Law of large programs): Large programs are even buggier than their size would indicate. Corollary 1,1: A security-relevant program has security bugs. Theorem 2: If you do not run a program, it does not matter whether it is buggy. Corollary 2.1: If you do not run a program, it does not matter whether it has security holes. Theorem 3: Exposed machines should run as few programs as possible; the programs that do run should be as small as possible. Sendmail wizard hole ____________________ The wizard-mode feature in sendmail was a special privileged remote debugging mode. Network access to the privileged mode was protected by a password specified in the configuration file. Not wanting to read the configuration file each time sendmail is launched, the system sets up and saves a pre-parsed frozen configuration; it writes bss (variables not explicitly initialized) and heap (for 'malloc') segments to a file. But one implementation declared the pointer to the _parsed_ password as: char *wizpw = NULL; (rather than char *wizpw) Hence, wizpw was explicitly initialized and therefore saved to the _data_ segment. The parsed password was not written to the frozen file, and the system acted as if there were no password. Anyone could 'telnet smtp', start wizard mode, and get privileged access to a debugging shell. Moral: being letter perfect in implementation isn't easy. The ftp/GNU tar hole ____________________ In fancy systems, 'ftpd' will allow a client to run 'tar' on the 'ftp' server (the remote host). Ah, but people started using feature-rich GNU tar. This allows: quote site exec tar -c -v --rsh-command= -f : Moral: new features mean new interactions. Previous message: [soen321-f04] building secure software (formatted) Next message: [soen321-f04] Fw: US-CERT Technical Cyber Security Alert TA04-260A -- Microsoft Windows JPEG component buffer overflow Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] More information about the soen321-f04 mailing list