1. Protection and Security Sarah Diesburg Operating Systems COP 4610

2. Definitions Security: policy of authorizing accesses  Prevents intentional misuses of a system Protection: the actual mechanisms implemented to enforce the specialized policy  Prevents either accidental or intentional misuses

3. Security Goals Data confidentiality: secret data remains secret Data integrity: unauthorized users should not be able to modify data System availability: nobody can make a system unusable

4. Security Components Authentication determines who the user is Authorization determines who is allowed to do what Enforcement makes it so people can do only what they are allowed to do

5. Authentication The most common approach: passwords  If I know the secret, the machine can assume that I’m the user Problems: 1. Password storage 2. Poor passwords

6. Password Storage Encryption  Uses a key to transform the data  Difficult to reverse without the key UNIX stores encrypted passwords in /etc/passwd  Uses one-way transformations  Encrypts a typed password and compares encrypted passwords

7. Poor Passwords Short passwords  Easy to crack Long passwords  Tend to be written down somewhere

8. Original UNIX Required only lower-case, 5-lettered passwords 26 5 or 1 million combinations  In 1975, it would take one day to crack one password  Today, we can go through all those combinations < 1 second

9. Partial Solutions Extend password with a unique number Require more complex passwords  6 letters of upper, lower cases, numbers, and special characters  70 6 or 100 billion combinations  Unfortunately, people still pick common words

10. Partial Solutions Delay every login by 1 second Assign very long passwords  Give everyone a password calculator (credit card)  Requires a physical theft to steal the password

11. Authentication in Distributed Systems Private key encryption of data  Encrypt(Key, Plaintext) = Cipher text  Decrypt(Key, Cipher text) = Plaintext Hard to reverse without the key With the plaintext and the cipher text, one cannot derive the key Provides secrecy and authentication, as long as the key stays secret

12. How to distribute the keys? Authentication server  Keeps a list of keys

13. Kerberos Protocol Key xy is needed to talk between x and y Server S Client B Client A Key AS Key BS Encrypt(Key AS, “I want Key AB ”)

14. Kerberos Protocol Key xy is needed to talk between x and y Server S Client B Client A Key AS Key BS Encrypt(Key AS,“Here is Key AB and a message to B”)

15. Kerberos Protocol Key xy is needed to talk between x and y Server S Client B Client A Key AS Key BS message Encrypt(Key BS, “use Key AB to talk to A”)

16. Additional Details Expiration timestamp for a key  Prevents a machine from replaying messages (e.g., “deposit $100”) Checksum for an encrypted message  Prevents modifications to a message (e.g., “deposit $1000”) Key AS and Key BS are renewed periodically to reduce their exposures

17. Public Key Encryption Separates authentication from secrecy Involves a public key and private key  Encrypt(Key public, plaintext) = cipher text  Decrypt(Key private, cipher text) = plaintext  Encrypt(Key private, plaintext) = cipher text  Decrypt(Key public, cipher text) = plaintext

18. Public Key Encryption Idea:  Private key is kept secret  Public key is advertised

19. Public Key Encryption Encrypt(Key my_public, “Hi, Sarah”)  Anyone can create it, but only I can read it (secrecy) Encrypt(Key my_private, “I’m Sarah”)  Everyone can read it, but only I can create it (authentication)

20. Public Key Encryption Encrypt(Key your_public, Encrypt(Key my_private, “I know your secret”))  Only I can create it, and only you can read it

21. Authorization Access matrix describes who can do what -The matrix tends to be sparse File 1Lisa’s diaryFile3 Bartread,writeread Lisaread, write Maggie

22. Access Control List Stores all permissions for all users with each object Analogy: a guard in front of a door  Checks for a list of people allowed to enter UNIX: permission of each file is specified according to its owner, group, and the world

23. Capability List Stores all objects a process can touch Analogy: Keys  A key owner has the right of entry Example: page tables  Each process has a list of pages that it can access

24. Access Control List vs. Capability List Access control list (commonly used)  Easy to know who can access the object  Hard to know which objects a user can access Capability list  A user knows the list of objects to access  Hard to know who can access an object More difficult to revoke capabilities

25. Enforcement Enforcer programs check passwords, access control lists, and so on… In UNIX, enforcers are run as superuser If there is a bug, you are hosed!

26. The State of the World in Security Authentication  Poor passwords  Nobody encrypts emails Authorization  Coarse-grained access control list  Often turned off for sharing Enforcement  Buggy operating systems

27. Classes of Security Problems Eavesdropping is the listener approach  Tap into the Ethernet and see everything  Countermeasure: pressurized cabled Abuse of privilege  If the superuser is evil, there is nothing you can do

28. Classes of Security Problems Imposter breaks into the system by pretending to be someone else  Recorded voice and facial image  Countermeasure: behavioral monitoring to look for suspicious activities Overwriting the boot block

29. Classes of Security Problems A Trojan horse is a seemingly innocent program that performs an unexpected function  Countermeasure: integrity checking Periodically, check binaries against their checksums

30. Classes of Security Problems Salami attack builds up an attack, one-bit at a time  Example: send partial pennies to a bank account  Countermeasure: code reviews

31. Classes of Security Problems Logic bombs: a programmer may secretly insert a piece of code into the production system  A programmer feeds the system password periodically  If the programmer is fired, the logic bomb goes off  Countermeasure: code reviews

32. Classes of Security Problems Denial-of-service attacks aim to reduce system availability  A handful of machines can flood a victim machine to disrupt its normal use  Countermeasure: open

33. Pentagon Traffic Analysis Before the 1991 Persian Gulf War  Foreign intelligence tried to predict the starting date of the war time

34. Pentagon Traffic Analysis So much for the element of surprise…

35. Tenex Used to be the most popular system at universities before UNIX Thought to be very secure

36. Tenex Source code for the password check: for (j = 0; j < 8; j++) { if (input[j] != pw[j]) { // go to error; } Need to go through 256 8 combinations

37. Tenex Unfortunately, Tenex used virtual memory A fast password check means that the first character is wrong (error) A slow check means that the first character is correct (page fault) password in memoryon disk

38. Tenex 256 8 checks to crack a password is reduced down to 256 * 8 checks

39. The Internet Worm In 1988, a Cornell graduate student, RTM, released a worm into the Internet The worm used three attacks  rsh  fingerd  sendmail

40. The Internet Worm Some machines trust other machines, the use of rsh was sufficient to get into a remote machine without authentication

41. The Internet Worm finger command did not check the input buffer size  finger name@location  Overflow the buffer  Overwrite the return address of a procedure  Jump and execute a shell (under root privilege)

42. The Internet Worm sendmail allowed the worm to mail a copy of the code and get it executed The worm was caught due to multiple infections  People noticed the high CPU load