Operating System Security.

1. Operating System Security. • Previous topic: Application security • Now: Use operating system as example for application security. • Overview of security provided by the operating system in accessing: • Memory • Files • Processes

2. Separation of memory. • The first resource that we will study is the memory. How does the OS protect the memory of one process from another?

3. Resource: Memory – Which OSes provide memory separation (2) • Memory separation is provided in the following OSes: • Windows NT and above. • UNIX, Linux, Mac OS X • Windows 9x family did not provide any separation  a user level program could access and modify the operating system memory!

4. Resource: Memory – What security issues are involved? • Memory is used by: • The Operating System (OS) • Processes that are running on the OS • Separation is therefore needed: • Between the OS and all the other processes. • E.g., user processes should not be able to overwrite or change the OS. • This is crucial! Why? An OS provides several security mechanisms (e.g., login, permissions on files etc.). • It is critical that these mechanisms cannot be tampered with by a regular user run program! • Between processes. • Between processes of the same user. E.g., a Word process should not interfere with Chrome (even if the same user is running both). • Also, between processes of different users.

5. Next: Separating memory between OS and all the other processes.

6. Separating memory between OS and other procesess: First option: limiting the hardware address. Architectures can “designate” a certain/fixed memory address, called “fence”. An OS is always stored between address 0 and the fence (e.g., n in the figure). Example: intel 386 and before: Fence used to be: 640K. Hence, an OS had to fit between 0 and 640 K. Any issues? Figure 4-1  Fixed Fence. Source for this slide: Required textbook: Security in Computing by Pfleeger and Pfleeger 4th Edition. Image from textbook Source for this slide: Required textbook: Security in Computing by Pfleeger and Pfleeger 4th Edition

7. Separating memory between OS and other procesess: Problems with the first option: limiting the hardware address. Issues with a fixed fence: Limits the size of the OS. (E.g., Inintex 286, the OS had to be 640 K or less). MS-DOS was less than 640 K. Figure 4-1  Fixed Fence. Source for this slide: Required textbook: Security in Computing by Pfleeger and Pfleeger 4th Edition Source for this slide: Required textbook: Security in Computing by Pfleeger and Pfleeger 4th Edition. Image from textbook

8. Separating memory: Second solution: allow “fence” to be determined by OS by designating a “register” as a fence register (address limit register). What’s a register? Every architecture (intel etc..) has a fixed amount of memory in their CPU’s – these are called registers. They are faster to access than cache or RAM. Figure 4-2  Variable Fence Register. Source for this slide: Required textbook: Security in Computing by Pfleeger and Pfleeger 4th Edition Source for this slide: Required textbook: Security in Computing by Pfleeger and Pfleeger 4th Edition. Image from textbook

9. So far … We saw: how to separate an OS from the rest of the processes using a “fence register”. However, this won’t separating one process from the other. It is limited to only separating an OS from other processes. Solution: use of a pair of registers called “base/bound” for each process.

10. Base/Bound registers. Every process has a base/bound Register. Base register: contains address of the Start of a process. Bound register: address of the end of a Process. Even the OS now has a base bound – So the OS can be loaded into any part of the memory – not just at address 0. Figure 4-3  Pair of Base/Bounds Registers. Source for this slide: Required textbook: Security in Computing by Pfleeger and Pfleeger 4th Edition

11. Base/Bound registers: separate processes, but not within the process (e.g., code from data inside a process) Figure 4-3  Pair of Base/Bounds Registers. Source for this slide: Required textbook: Security in Computing by Pfleeger and Pfleeger 4th Edition. Image from textbook

12. Data, Program (code) registers. Allow separation betweenaprogram's “code” its and “data”.Why? This prevents data from being accidentallytreatedas code. Source for this slide: Required textbook: Security in Computing by Pfleeger and Pfleeger 4th Edition. Image from textbook

13. Summary so far … • Memory fence separates OS,user memory. • base/bound registers separate process mem. • Data/Code segment registers separate data and code within a process. • Finally: Within a process, some data is “read only” (e.g., finals/constants in a program). • This is achieved using a “tagged architecture”.

14. Protecting other objects. • Protecting memory is easy: • The hardware provides registers that can be used as fences. • Whenever a process accesses memory, the memory address it is seeking can be checked with the register value. • Illegal accesses can be flagged. • There is only one way to access memory – through hardware. • Hence, the OS is able to completely mediate access to memory. • But protecting other objects (e.g., files, passwords, directory of files, a hardware device) is not so easy: • First the access may not be just read, write or execute. • The number of ways to access a particular object maybe several. E.g., a file can be accessed by using the OS – or simply by removing the disk and attaching it to another machine.

15. UserIDs and Group IDs • In order to separate: the OS must first need to identify users. It does this: • By authentication (e.g., using passwords). • After authentication the user becomes a number on the system: called user id. • In all GPOSes (general purpose Operating Systems), every user has a specific unique user id. • The administrator (also called root in UNIX) has a user id of 0. • Exercise in class: access the “/etc/passwd” file in UNIX to see the userids. • When a user logs in, every program executed by the user starts running with the user id of that user. • The same userid is used as part of the Access control list to assign permissions to resources.

16. UserIds and GroupIDs. • User Ids, Group Ids are often stored in/etc/passwd or inC:\Windows\system32\config\SAM • An example entry from /etc/passwd file: root:*:0:0:System Administrator:/var/root:/bin/sh • Windows/UNIX access control policy: A program running with a specific user id can access (read, write, or execute) any resource which that specific user id is permitted to access. • E.g., if a root is editing a document in Microsoft Word. That same process MS Word can be used to open and edit, say, the password file.

17. UserIDs and Group IDs • Example: • Consider a file in a GPOS with associated permissions in UNIX/Linux (simply run “ls -lt” to obtain this output). • If a user Alice logs into the computer, can she: • Open the file passwd in program MS word for reading? • Open the file passwd in program MS word for writing? A program can only access a resource if the user executing the program has permissions to access that resource. -rw-r--r-- 1 root wheel 1932 Jan 13 2006 /etc/passwd Permissions:User can read/write; Group can read;Others can read group owner

18. Summary • We have seen how OSes protect memory. • Next: • How to protect other objects (other than memory)? • Authenticating users: passwords. • File system protection and access control. • Types of access control.

19. Minding our language … • Permissions: access rights associated with a resource. E.g., “read” permission on a file. • Privileges: access rights given to a program to do a task. E.g., Does MS word executed by Bob has the permissions to write into Alice’s folder? • Both permissions and privileges almost mean the same. But sometimes are different. • Administrator = root = superuser = wheel = admin

20. Goals in protecting objects. • To protect an object such as a file, we need mechanisms that satisfy these goals: • Check every access (called the principle of complete mediation). • Enforce least privilege (principle of least privilege). • Verify acceptable usage . • Next: looking at some of the OS mechanisms that provide these features.

21. Next: Authenticating identity.The concept of passwords. • Authentication is usually based on one or more of the following: • Something you know. E.g. PIN • Something you have. E.g., card. • Something you are. E.g., Fingerprint. • Usually a good system will require atleast two or more of the above ways of authentication (called 2 point authentication). • This is an example of the principle of separation of privileges. Source for this slide: Required textbook: Security in Computing by Pfleeger and Pfleeger 4th Edition. Image from textbook

22. Threats to passwords. • What threats can you think of to passwords?

23. Password Security • Many applications use login names and passwords • Password systems are vulnerable to attack • Early password security studies (1979) • Morris, Thompson:86% of user passwords could be cracked • Threat: • Dictionary Attacks – attacks where dictionary is used to guess passwords. • Reading the passwords from the disk. E.g., user copies the password file and then tries to crack passwords. • Next: OS mechanisms to protect against these threats. Citation for the slide including notes: Foundations of Security: What Every Programmer Needs to Know by Neil Daswani et.al, ISBN:  978-1590597842

24. Password Security • Approaches (we will study each of these …): • make password file non-readable by all users (e.g., shadow passwords in UNIX and Windows) • Do not store the passwords on disk – instead store their secure hashes. • Use “salt” with passwords to make it harder to guess. Citation for the slide including notes: Foundations of Security: What Every Programmer Needs to Know by Neil Daswani et.al, ISBN:  978-1590597842

25. Password security and use of secure hash functions. • Passwords need to be stored on the disk. • The first passwords were stored in clear text – is this a good idea? • One solution is to “encrypt” the password using a symmetric key cipher (e.g., DES). Why is this not a great idea?

26. Password security and use of secure hash functions (2). • One solution is to “encrypt” the password using a symmetric or public key cipher (e.g., DES or RSA). Why is this not a great idea? • Symmetric or asymmetric (public) ciphers use a secret key or a private key. Where can the OS store this private key? • So now the problem is: how to store the secret key used in encryption? Storing that in clear text is not a good idea either. Encrypting it is not a great idea either – because to encrypt you will need another secret key. How to store this new secret key – This becomes a major problem. • Solution: Use secure hash functions. Secure hash functions do not require a “secret key”.

27. Hashing Passwords Instead of storing the actual password on disk – UNIX/Linux/Windows/Mac OS store a “secure hash” of the password. Remember, if someone gets a hash they cannot get the original input. This was one of the conditions behind the hash function. (Remember: secure hash is different from encryption/ Decryption; it's one-way.) /etc/passwd: john EOINJHGHGFDJKHSD mary DKYFBHNUISHDFIUB joe LIXBNEYGSOPDKEGF Citation for the slide including notes: Foundations of Security: What Every Programmer Needs to Know by Neil Daswani et.al, ISBN:  978-1590597842

28. Using Hashing Passwords “What is your username & password?” Does hash("automobile") = "LIXBNEYGSOPDKEGF" I.e., compare hash with the stored hash. My name is Joe. My password is automobile. To check a password: • The login program or SSH program on the • OS asks user to enter password. • OS then generates a hash value of the • entered password. • (3) OS compares this hash value with that in • the password file. If they match – login else • teject. /etc/passwd: john EOINJHGHGFDJKHSD mary DKYFBHNUISHDFIUB joe LIXBNEYGSOPDKEGF Citation for the slide including notes: Foundations of Security: What Every Programmer Needs to Know by Neil Daswani et.al, ISBN:  978-1590597842

29. h("automobile") = "LIXBNEYGSOPDKEGF" h("aardvark") = "DOPIDFKMOSIHFDXS" h("balloon") = "DKYFBHNUISHDFIUB" h("doughnut") = "DKLJDFUISNHDFKUJ" STEP 1: Attacker Obtains Password File: /etc/passwd: john EOINJHGHGFDJKHSD mary DKYFBHNUISHDFIUB joe LIXBNEYGSOPDKEGF Off-line Dictionary Attack on stored hashes of passwords. Hashing passwords makes it harder to use a passwd file, but easy passwords can still be broken! Here’s an example. STEP 2: Attacker computes possible password hashes(using words from dictionary) Citation for the slide including notes: Foundations of Security: What Every Programmer Needs to Know by Neil Daswani et.al, ISBN:  978-1590597842

30. h("automobile") = "LIXBNEYGSOPDKEGF" h("aardvark") = "DOPIDFKMOSIHFDXS" h("balloon") = "DKYFBHNUISHDFIUB" h("doughnut") = "DKLJDFUISNHDFKUJ" Off-line Dictionary Attack on stored hashes of passwords (2). /etc/passwd: john EOINJHGHGFDJKHSD mary DKYFBHNUISHDFIUB joe LIXBNEYGSOPDKEGF Step 3: Attacker determines that Mary’s password is “balloon!” Attacker computes possible password hashes(using words from dictionary) Source for the slide: Foundations of Security: What Every Programmer Needs to Know by Neil Daswani et.al, ISBN:  978-1590597842

31. h("automobile") = "LIXBNEYGSOPDKEGF" h("aardvark") = "DOPIDFKMOSIHFDXS" h("balloon") = "DKYFBHNUISHDFIUB" h("doughnut") = "DKLJDFUISNHDFKUJ" Off-line Dictionary Attack on stored hashes of passwords (3). Computing the hash values of every word in a dictionary is time-consuming. So attackers pre-compute a file with every word and its hash. Then, sort this file by the hashes; looking up whether a hash happens to be a hash of a dictionary word is now a binary search (fast). Then, if they gain access to a list of hashed passwords, it is quick to look at each one and see if it's the hash of a dictionary word. Very fast. Source for the slide: Foundations of Security: What Every Programmer Needs to Know by Neil Daswani et.al, ISBN:  978-1590597842

32. How to prevent off-line dictionary attacks? • Not too many choices…cannot be easily prevented. • However, a small pseudo random number known as “salt” helps a bit when the attacker uses “pre-computed” hashes on dictionary. • Recall: we said • It is time-consuming for an attacker to hash every dictionary word when breaking a password. • So attacker pre-computes hashes and sorts, reusing them everytime he/she has to crack passwords . The goal of adding salt to hashes is to make a pre-computed hash of a dictionary worthless. Source for the slide: Foundations of Security: What Every Programmer Needs to Know by Neil Daswani et.al, ISBN:  978-1590597842

33. “What is your username & password?” Does h("automobile2764") = "LDHNSUNELDUALKDY" ??? My name is Joe. My password is automobile. Salting Hashed Passwords Along with each password, UNIX/Windows stores a “salt” value – a pseudo random number. E.g., “joe”’s password salt: • The salt is different for each user. /etc/passwd: john LPINSFRABXJYWONF 2975 mary DOIIDBQBZIDRWNKG 1487 joe LDHNSUNELDUALKDY 2764 When checking password – the salt is read from the password file and concatenated with the password before hashing. How does this help? Citation for the slide including notes: Foundations of Security: What Every Programmer Needs to Know by Neil Daswani et.al, ISBN:  978-1590597842

34. Off-line Dictionary Foiled (or made harder)! h(automobile0001) = KNVXKOHBDEBKOURX h(automobile0002) = ZNBXLPOEWNVDEJOG h(automobile0003) = ZMCXOSJNFKOFJHKDF h(automobile0004) = DJKOINSLOKDKOLJUS … h(aardvark0001)= DKOUOXKOUDJWOIQ h(aardvark0002)= PODNJUIHDJSHYEJNU …Etc… Assume attacker wants to use pre-computed hashes of a Dictionary. To pre-compute the attacker needs to hash both a dictionary word and a salt: E.g., if Joe’s password is automobile and salt value is 2764, then what the OS actually stores on the disk is hash(automobile2764). To use a pre-computed dictionary, attacker now not only has to pre-compute hash(automobile) but actually hash(automobile1), hash(automobile2) …. Etc... So basically, number of things to pre-compute has been increased, drastically. By how much – next slide example Too many combinations!!! Attack is Foiled! Citation for the slide including notes: Foundations of Security: What Every Programmer Needs to Know by Neil Daswani et.al, ISBN:  978-1590597842

35. Off-line Dictionary Foiled (or made harder)! • Consider a simple example – let us say password of Joe is a dictionary word from the Merriam-Webster dictionary. • Now: Assume this dictionary has 470000 words. • Let, • Joe’s password be: “automobile” • hash of this be: h(automobile) = LIXBNEYGSOPDKEGF • Mary’s password be: “balloon” • hash of this be: h(vehicle) = DKYFBHNUISHDFIUB • Now, to break this in an offline attack – the attacker does the following: • PRE-COMPUTE Go through the entire dictionary and compute hash of each word. • For both Joe and Mary, do a reverse look-up of the hashes LIXBNEYGO… and DKYFB… and obtain the passwords. • Next: Let us see how a salt can make this harder. Citation for the slide including notes: Foundations of Security: What Every Programmer Needs to Know by Neil Daswani et.al, ISBN:  978-1590597842

36. Off-line Dictionary Foiled (or made harder)! • Assume a salt can be a max of 4 digits (e.g., 1000 or 1001). • Now: Assume that dictionary has 470000 words. • Let, • Joe’s password be: “automobile”; Let salt for Joe be: 2764 • hash of this: h(automobile2764) = LIXBNEYGSOPDKEGF • Mary’s password be: “balloon”; Let salt for Mary be: 1001 • hash of this be: h(balloon2764) = DKYFBHNUISHDFIUB • Now, to break this in an offline attack – the attacker does the following: • PRE-COMPUTE Go through the entire dictionary and compute hash of each word. However this won’t work – because now the hash that the attacker has to reverse lookup is the word + salt. • Hence, attacker has to pre-compute for each word in the dictionary: • Hash (word + each possible salt). • With 4 digits, 10000 salts are possible (0000 to 9999). Hence, for each word 10000 more pre-computations. •  for 470000 words, pre-computation now requires: 470000 * 10000 computations! • So! A salt increased the difficulty of pre-computation by 10000 times! Citation for the slide including notes: Foundations of Security: What Every Programmer Needs to Know by Neil Daswani et.al, ISBN:  978-1590597842

37. Where Salt is not useful. • Salt is useful: • If attacker is using pre-computed dictionary words. • But if attacker computes on the fly – the attackers code can easily read the “salt” value and then find hash. These days, doing this is not computationally challenging. • If attacker is running an “online” brute-force attack. • E.g., trying to guess the password on gmail online account by trying out various combos. • Doesn’t matter if salt is used…as one combo may work.

38. More Password Security • Shadow Passwords • Make password file inaccessible to non-root users in /etc/shadow • “Booby-traps” (guest/guest) – keep an easy to break account so attacker doesn’t try other accounts (doesn’t work). Citation for the slide including notes: Foundations of Security: What Every Programmer Needs to Know by Neil Daswani et.al, ISBN:  978-1590597842

39. Password Security • Can you think of other techniques to make passwords harder to crack?

40. Password Security: some solutions to make attacks harder • Other Tools / Techniques for good password security: • Strong Password Suggestions • Password Filtering • Aging Passwords • Pronounceable Passwords • Limited Login Attempts / Acct Locking ( • E.g., using captchas – these are the human readable but machine unreadable words or images that are displayed when you make too many wrong login attempts) • Artificial Delays • Display Last Date, Time, & Location • User Education Citation for the slide including notes: Foundations of Security: What Every Programmer Needs to Know by Neil Daswani et.al, ISBN:  978-1590597842

41. Figure 4-15  Users’ Password Choices. Source for this slide: Required textbook: Security in Computing by Pfleeger and Pfleeger 4th Edition. Image from textbook

42. Another security mechanism: One-time Passwords • Uses a password-generating device. • Can be integrated into a PDA, cell phone, or other mobile device • A password cannot be used more than once…user has a list of all passwords with the help of a device. Source for this slide: Required textbook: Security in Computing by Pfleeger and Pfleeger 4th Edition. Image from textbook

43. Password guessing software. • A good technique to ensure passwords by users are secure is to simply try and crack them (if you are a system admin with the privileges to do this). • Software tools are available. • Cain and Abel – very powerful password cracker for Windows. • Aircrack • John the ripper • Etc…

44. Password Security: Summary • Hashing passwords • Dictionary Attacks • Salting • Enhancements • One-time Passwords • Password Guessers Source for this slide: Required textbook: Security in Computing by Pfleeger and Pfleeger 4th Edition. Image from textbook

45. After authentication, comes authorization. • After OSes authenticate they authorize the user. • Use the user ids to control access to objects (Access control). Source for this slide: Required textbook: Security in Computing by Pfleeger and Pfleeger 4th Edition. Image from textbook

46. Authorization. • There are various ways to authorize. • They all fall under the area of “access control”, i.e., controlling the access to a certain object (e.g., a file).

47. Authorization • Authorization can range from simple rules to very complex fine-grained rules. • Examples: • Simple rules: • User ABC can only access files in folder C:/ • User ABC cannot execute any program for more than 20 minutes. • Complex rules: • Military/secret agency situations: The Vice-President can read information about a secret agent and can share that information with her/his Chief of Staff, but not with the Press and only some members of Congress.

48. Authorization (2) • Authorization in Operating Systems • Most OSes (Windows, Linux) maintains a data structure (list) called Access Control List (ACL). • ACLs contain a list of users, the resources each user can access, and the set of permissions with which the user can access the resources. • E.g, consider a file in the following folder: C:\Document and Settings\Bob\493Project.doc The OS maintains the following information: • Which user can access the file 493Project.doc E.g., can Bob access the file? • In what way can Bob access the file? E.g., can he read the file, change the contents (write) of the file or both? Can he even see the last-changed date?

49. Authorization (3) • Simple ACL User Resource Privilege Alice C:\My Documents\Alice read, write Bob C:\My Documents\Bob read, write, execute Most Operating systems also assign “roles” or group users. E.g., Bob Student, SecurityGroup // Alice belongs to Student and Security group. Alice Faculty, SecurityGroup. Then an ACL such as this will give same permissions to both Bob and Alice: SecurityGroup C:\SecurityDocs read, write

50. Access Control Models • Access control models Consider the following two scenarios: • Scenario 1: In a University where computers are public and accessed by many people. There are many students and the student body is a rotating population (I.e., students graduate). Assume student Bob writes a song in a file. Should Bob be able to share the song with whomever he wants to? • Scenario 2: A spy, Alice, creates a secret document about a country’s intention to acquire high protein tomatoes. Now, Should Alice be able to share the info on the tomatoes with whomever she wants to? In both scenarios, Alice and Bob were the ones who created the file. However, their ability to assign permissions is different. To capture such different scenarios we use what are called Access Control models (What are the different ways to control access to files).