Security CSE473 - Spring 2008 Professor Jaeger - PowerPoint PPT Presentation

Security CSE473 - Spring 2008 Professor Jaeger www.cse.psu.edu/~tjaeger/cse473-s08/ CSE473 Operating Systems - Spring 2008 - Professor Jaeger

Protection • Protect yourself from untrustworthy users in a common space – If protection is so good, then why do we have so many vulnerabilities/attacks? • UNIX vulnerabilities • Windows vulnerabilities CSE473 Operating Systems - Spring 2008 - Professor Jaeger Page 2

UNIX Vulnerabilities • Malware can trick a UNIX system in several ways • Act as you – All programs you run, run with your user id – Can do anything you can do • Leak/modify any of your data • Change your permissions – You can change your permissions -- so can your programs – So, even if you have carefully designed your permissions • Malware can undo them • Trick setuid programs – Trusted programs that can be run by anyone • Including malware – If you can craft malicious inputs then... • And we haven’ t even discussed program vulnerabilities CSE473 Operating Systems - Spring 2008 - Professor Jaeger Page 3

The Morris Worm • Robert Morris, a 23 year old doctoral student from Cornell – Wrote a small (99 line) program – November 3rd, 1988 – Simply disabled the Internet • How it did it -- summary – Buffer overflow on the fingerd program -- has root access – Cracks user passwords on the compromised host to try on other hosts – Used liberal system configurations of the time to identify hosts that accept logins without a password from the compromised host – Scanned local interfaces for network information – Covered its tracks (set is own process name to sh , prevented accurate cores, re-forked itself) • Became significant because it would re-attack an already infected system after 7 scans CSE473 Operating Systems - Spring 2008 - Professor Jaeger Page 4

Link Vulnerabilities • Add new path to an inode • Multiple names for a single inode • Run – ln -s /etc/passwd badlink – setuid_program badlink < *passwd-entry* – To overwrite /etc/passwd • Programs have to be aware of which files they are using • open(file, O_NOFOLLOW, mode) – Prevents open from following a link • Also, problems with access, then open – File name to inode mapping causes problems CSE473 Operating Systems - Spring 2008 - Professor Jaeger Page 5

/tmp Vulnerability • creat(pathname, mode) • O_EXCL flag – if file already exists this is an error • Potential attack – Create file in shared space (/tmp) – Give it a filename used by a higher authority service – Make sure that service has permission to the file – If creat is used without O_EXCL, then can share the file with the higher authority process CSE473 Operating Systems - Spring 2008 - Professor Jaeger Page 6

Windows Vulnerabilities • And Windows has been worse • Many vulnerable programs – SQL server -- leveraged by Code Red • Many misconfigurations – All ISS Services were enabled by default -- Code Red again • Additional challenges – Registry is a centralized store of information that is accessible to malware • Extensible systems – Easy to install malware (keyloggers, spyware, bots) • The story has improved some in software engineering, but we still have significant issues CSE473 Operating Systems - Spring 2008 - Professor Jaeger Page 7

Secrecy • Does the following protection state ensure the secrecy of J ’ s private key in O 1 ? O 1 O 2 O 3 J R R R W W S 2 N R R W S 3 N R R W CSE473 Operating Systems - Spring 2008 - Professor Jaeger Page 8

Integrity • Does the following access matrix protect the integrity of J ’ s public key file O 2 ? O 1 O 2 O 3 J R R R W W S 2 N R R W S 3 N R R W CSE473 Operating Systems - Spring 2008 - Professor Jaeger Page 9

Trusted Processes • Does it matter if we do not trust some of J ’ s processes? O 1 O 2 O 3 J R R R W W S 2 N R R W S 3 N R R W CSE473 Operating Systems - Spring 2008 - Professor Jaeger Page 10

Protection vs Security • Protection – Security goals met under trusted processes – Protects against an error by a non-malicious entity • Security – Security goals met under potentially malicious processes – Protects against any malicious entity • For J: – Non-malicious process shouldn ’ t leak the private key by writing it to O 3 – A potentially malicious process may contain a Trojan horse that can write the private key to O 3 CSE473 Operating Systems - Spring 2008 - Professor Jaeger Page 11

Reference Monitor • Guarantees – Complete mediation of all security-sensitive operations – Tamperproof – Simple enough for verification of correctness CSE473 Operating Systems - Spring 2008 - Professor Jaeger Page 12

Complete Mediation • Ensure that OS operations that impact security are mediated Entry Points Entry Points System System Interface Interface Access Access Hook Hook Authorize Request? Security-sensitive Security-sensitive Access Access Operation Operation Access Access Monitor Monitor Hook Hook Hook Hook Policy Policy Security-sensitive Security-sensitive Security-sensitive Security-sensitive Operation Operation Operation Operation Yes/No CSE473 Operating Systems - Spring 2008 - Professor Jaeger Page 13

Tamperproof - Trusted Computing Base • Programs upon which the correct enforcement of security depends , including... – BIOS, Bootloader, ... – Operating system – Trusted services • Initialization, administration, installation, ... – Privileged programs • Authentication, network facing daemons, root programs – Programs run by administrative users • Could be anything – Programs entrusted by the system for enforcement • Servers (mail, web, etc) -- support multiple users • Clients (browser, email, etc) -- control the user ’ s data • In order to verify, TCB must be manageable CSE473 Operating Systems - Spring 2008 - Professor Jaeger Page 14

Tamperproof - Mandatory Access Control • Discretionary Access Control – UNIX and Windows use this – File “owners” can modify their file permissions • Add so can their programs • Mandatory Access Control – System-defined protection state – System-defined labels of processes and file • Cannot be modified by users or their programs – So, can define specific security goals – And depend on them being enforced • Challenge: Flexibility CSE473 Operating Systems - Spring 2008 - Professor Jaeger Page 15

Verification • What are the security goals of a system? – How do we determine that they are met? • Showing that a program is doing the right thing is an intractable problem in general – And systems are extensible... • So, we have simple goals for complex systems CSE473 Operating Systems - Spring 2008 - Professor Jaeger Page 16

Secrecy Goal - Multilevel Security • A multi-level security system tags all object and subject with security tags classifying them in terms of sensitivity/access level. – We formulate an access control policy based on these levels – We can also add other dimensions, called categories which horizontally partition the rights space (in a way similar to that as was done by roles) security levels categories CSE473 Operating Systems - Spring 2008 - Professor Jaeger Page 17

MLS Example Access is allowed if subject clearance level >= object sensitivity level and subject categories ⊇ object categories ( read down ) Q: What would write-up be? Hence, Charlie: TS, {CRYPTO, NUC, INTEL}) Bob: CONF., {INTEL}) Alice: (SEC., {CRYTPO, NUC}) DocB: (SECRET, {CRYPTO}) DocA: (CONFIDENTIAL, {INTEL}) DocC: (UNCLASSIFIED , {NUC}) CSE473 Operating Systems - Spring 2008 - Professor Jaeger Page 18

Integrity Goal - Biba Integrity • Biba defined a dual of secrecy for integrity – Lattice policy with • No read down • No write up – Q: Why would this work? • The lattice model for secrecy matched the paper world, does this integrity model? • What is a realistic view of integrity? CSE473 Operating Systems - Spring 2008 - Professor Jaeger Page 19

UNIX/Windows are Not Reference Monitors • Why do current protection systems fail to meet these? – Complete mediation • Do not identify and enforce all security-sensitive operations • Processing is not attributed correctly -- your malware runs as you – Tamperproof • Can modify policy • Extensible systems and kernels – Simple enough to verify • All programs that can perform setuid are in the TCB (all programs) • Policies do not ensure secrecy and integrity • So, they are not even close to enforcing security! CSE473 Operating Systems - Spring 2008 - Professor Jaeger Page 20

Secure Systems • Have any ever been built? Yes and no. – An open and completely secure system is not possible – But, their have been a variety of attempts at providing real security in systems • However, these have been of limited use and discussion – Seminal multiprogrammed OS: Multics • Many of the security concepts were developed in 60 ’ s and 70 ’ s – Security kernels • Scomp, GEMSOS, XTS-300/400, STOP, ... – MLS systems • Trusted Solaris, SELinux, various other systems – Virtualization • The next wave CSE473 Operating Systems - Spring 2008 - Professor Jaeger Page 21