Stanford CS 155 - Running Unreliable Code

Unformatted text preview:

1Running Unreliable Code John MitchellCS155TopicuHow can you run code that could contain a dangerous bug or security vulnerability?uExamples:• Run web server, may have buffer overflow attack• Run music player, may export your files to networkSeveral Historical ApplicationsuTest and debug system code• Contain or monitor execution to find bugsuExtensible Operating Systems• Modern trend toward smaller kernel, more functionality provided by useruUntrusted code from network• Download from web• Code installed by browseruSecure System Composition• Want to construct a secure system from mix of highly assured components and COTSMany uses for extensibilityuOS KerneluWeb browseruRouters, switches, active networksuServers, repositoriesCommon problem:• Give untrusted code limited access to resources, without compromising host integrityuntrustedhostThis lectureuConventional OS: chroot and jailuFour approaches for compiled code• Code modification for run-time monitoring• System call interposition• Proof-carrying code• Virtual machines (e.g., VMWare)uNext lecture• Browser security• Java securityConventional OSuKeep processes separate• Each process runs in separate address space• Critical resources accessed through systems calls– File system, network, etc.uAdditional containment options • chroot• jail2Unix chrootuchroot changes root directory• Originally used to test system code “safely”• Confines code to limited portion of file system uExample use• chdir /tmp/ghostview• chroot /tmp/ghostview• su tmpuser (or su nobody)uCaution• chroot changes root directory, but not current dir– If forget chdir, program can escape from changed root• If you forget to change UID, process could escapeOnly root should execute chrootuOtherwise, jailed program can escape– mkdir(/temp) /* create temp directory */– chroot(/temp) /* now current dir is outside jail */– chdir(“ ../../../.”) /* move current dir to true root dir */– chroot(“.”) /* out of jail */Note: this is implementation dependentuOtherwise, anyone can become root– Create bogus file /tmp/etc/passwd– Do chroot(“/tmp”)– Run login or su (if exists in jail)History: In Ultrix 4.0, chroot could be executed by anyoneFree BSD jail commanduExample• jail apacheuStronger than chroot• Calls chroot• Also limits what root can do– Each jail is bound to a single IP address• processes within the jail may not make use of any other IP address for outgoing or incoming connections– Can only interact with other processes in same jailProblems with chroot, jail approachu Too coarse • Confine program to directory– but this directory may not contain utilities that program needs to call• Copy utilities into restricted environment – but then this begins to defeat purpose of restricted environment by providing dangerous capabilitiesu Does not monitor network accessu No fine grained access control• Want to allow access to some files but not othersExtra programs needed in jailuFiles needed for /bin/sh/usr/ld.so.1 shared object libraries/dev/zero clear memory used by shared objects/usr/lib/libc.so.1 general C library/usr/lib/libdl.so.1 dynamic linking access library/usr/lib/libw.so.1 Internationalization library/usr/lib/libintl.so.1 Internationalization librarySome othersuFiles needed for perl• 2610 files and 192 directories How can we get better protection?uGoals• Finer-grained protection– Enforce more sophisticated policies than “every process can only execute own instructions and touch own memory”• More efficient fault isolationuRelevant security principles• Compartmentalize• Least privilege• Defense in depth3Rest of lectureuSystem Monitoring• Software Fault Isolation– Modify binaries to catch memory errors • Wrap/trap system calls– Check interaction between application and OS• Theoretical and practical limit: safety propertiesuCheck code before execution• Proof-carrying code– Allow supplier to provide checkable proofuVirtual Machines (e.g., VMWare; JVM next lecture)• Wrap OS with additional security layerSoftware Fault Isolation (SFI)uWahbe, Lucco, Anderson, Graham [SOSP’93]• Collusa Software (founded ’94, bought by Microsoft ‘96)uMultiple applications in same address spaceuPrevent interference from memory read/writeuExample• Web browser: shockwave plug-in should not be able to read credit-card numbers from other pages in browser cacheSFI is old idea in OS, made obsolete by hardware support for separate process address spaces, now considered for performance, extensible OSWhy software protection?uCompartmentalize and use least privilegeMore compartmentalization⇒ More processes if each is separate process⇒ More context switches and inter-process communicationuUseful to achieve OS-level protection (or better) without overhead of OS context switchu Partition memory space into segments u Add instructions to binary executables • Check every jump and memory access• Target location must be in correct segment– All locations in segment have same high-order bitsSFI idea: Code segment Data segmentCode segment Data segmentCode segment Data segmentApplication 1Application 2Application 3Check jumps and memory accessu Consider writes (Jumps are a little simpler)u Replace each write by the sequence:dedicated-reg ⇐ target addressscratch-reg ⇐ (dedicated-reg >> shift-size)scratch-reg == segment-regtrap if not equalstore through dedicated-regu This requires several registers:• Dedicated-reg holds the address being computed– Needed in case code jumps into middle of instrumentation• Segment-reg hold current valid segment• Shift-size holds the size of the shift to performSlide credit: Alex AikenA Faster ApproachuSkip test; Just overwrite segment bitsdedicated-reg ⇐ target-reg & mask-regdedicated-reg ⇐ dedicated-reg | segment-regstore through dedicated-reg uTradeoffs• Much faster– Only two instructions per instrumentation point• Loses information about errors– Program may keep running with incorrect instructions and data• Uses five registers– 2 for code/data segment, 2 for code/data sandboxedaddresses, 1 for segment mask4OptimizationsuUse static analysis to omit some tests• Writes to static variables• Small jumps relative to program counteruAllocate larger segments


View Full Document

Stanford CS 155 - Running Unreliable Code

Documents in this Course
Lecture 5

Lecture 5

64 pages

Phishing

Phishing

31 pages

Load more
Download Running Unreliable Code
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Running Unreliable Code and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Running Unreliable Code 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?