MIT OpenCourseWare http://ocw.mit.edu 6.033 Computer System Engineering Spring 2009 For information about citing these materials or our Terms of Use, visit: http://ocw.mit.edu/terms.Security introNickolai Zeldovich ============== key ideas for today:key to security is understanding what the attacker can doprinciples: reduce trust (least privilege), economy of mechanism --- board 1 ---security / protectionpermeates computer system designif you don't design it right upfront, can be hard to fix latermuch like naming, network protocols, atomicity, etcwill affect all of the above give examples of security problemsSLIDE: general security stats critical problems that allow attackers to take control over windows machines -- about once a week SLIDE: not surprising, then, that china controls computers in embassiesSLIDE: even medical devices like pacemakers are vulnerable to attacks so what is protection? back to first board prevent access by bad guysallow access by good guyspolicies [lots of them, and we can't really cover all possibilities][.. so much like with other topics] -> mechanism --- board 2 ---real world vs computer securitysame: lock - encryption checkpoints - access control laws, punishment different: attacks are fast, cheap, scalable ~same effort to compromise 1 or 1,000,000 machines can compromise machines all over the world no need to physically be present at the machine no strong notion of identity global; few laws --- board 3 ---policy goals: positive vs negativeNickolai can read grades.txt -- easywhy easy? build system, if it doesn't work, keep fixing until it doesJohn cannot read grades.txt -- hardseems just the opposite of the abovewe can try asking John to log in and try to access grades.txtnot enough: have to quantify all possible ways John might get grades.txttries to access the disk storing the file directlytries to access it via a browser (maybe web server has access?)tries to read uninitialized memory after Nickolai's editor exitstries to intercept NFS packets that are reading/writing grades.txt tries to sell you a malicious copy of Windowstries to take the physical disk out of server and copy ittries to steal a copy of printout from the trashcalls the system administrator and pretends to be Nickolaihard to say "regardless of what happens, John will not get grades.txt" not enough to control access via one interface must ensure all possible access paths are secure we've seen some positive goals (e.g. naming) in 6.033 alreadysome negative goals too (transaction must not be "corrupted")security is harder because attacker can do many thingswith transactions, we knew what's going to happen (crash at any point)most security problems are such negative goals --- board 4 ---threat model the most important thing is to understand what your attacker can dothen you can design your system to defend against these things C -> I -> S typical setting:client named Alice, server named Boban attacker (router) in the network, Eve, is eavesdroppingalternatively, Lucifer, a malicious adversary, can send, modify packets does attacker control the client? server? frequent assumption: no physical, social engineering attacks only intercept/send messages might or might not compromise server, client this picture applies even on a single machine processes from diff. users making calls into the OS kernel consider costs as well (both security and insecurity have a price)convenience, HW expense, design, .. right side of the board:basic goals- authentication [SLIDE: kentucky fax]- authorization [who is authorized to release prisoners?]- confidentiality NOTE: quite diff. from authentication!- auditing- availability --- board 5 ---policies / mechanismshardware: confine user code mechanism: virtual memory, supervisor bitauthentication: kernel initializes page table, supervisor bitHW knows current state authorization: can access any virtual memory address in current PTcannot access privileged CPU stateUnix: private files mechanism: processes, user IDs, file permissions authentication: user password, when user starts a process authorization: kernel checks file permissions firewalls: restrict connections mechanism: packet filtering authentication: connection establishment authorization: list of allowed/prohibited connections seemingly weak mechanism, but surprisingly powerful in practice bank ATM: can only withdraw from your acct, up to balance mechanism: app-level checks in server process authentication: card & PIN authorization: track account balance cryptography: next lectures --- board 6 ---challengesbugshard to build bug-free systems, write perfect codeexpect bugs, try to design your system to be secure despite themin recitation tomorrow, will look at some of these bugscomplete mediation requires careful design SLIDE: paymaxx bug many mechanisms: hard to enforce coherent policy want to ensure that bank policies are followed what mechanisms do we have? virtual memory isolates processes kernel, file system implements ACLs bank ATM implements its own checks web banking might implement other checks system used by bank employees has other checks firewalls at different places in the network interactions between layers [caching/timing, naming, memory reuse, network replay] SLIDE: naming problem with symlink attacks SLIDE: password checking one character at a time --- board 7 ---safety net approachbe paranoid -- make assumptions explicitattackers will try all possible corner casesconsider the environment if you are relying on network security, check for open wireless networksif you are reusing, relying on another component, make sure it's securecode meant to run on non-networked system used on the web? never expected to deal with malicious inputs consider dynamics of use suppose only Nickolai should access grades.txt who can specify permissions for the grades file?who can modify editor on Athena? or set permissions on it?who can control name translation for that file? defend in deptheven if you have a server on a "secure" company network, still wantto require passwords. what if someone brings an infected laptop? right side of the board:humans: weakest link - UI - safe defaults --- board 8 ---design principlesopen design, minimize secretsfigure out what's going to differentiate bad guys vs good guysfocus on protecting that, make everything else publicauthentication: ID public, sth. that proves you're that ID is secretSSNs, credit card numbers fail at thisSSNs used both as ID and as credentials
View Full Document
Unlocking...