A Secure Environment for Untrusted Helper Applications (Confining the Wily Hacker)
Total Page:16
File Type:pdf, Size:1020Kb
The following paper was originally published in the Proceedings of the Sixth USENIX UNIX Security Symposium San Jose, California, July 1996. A Secure Environment for Untrusted Helper Applications (Confining the Wily Hacker) Ian Goldberg, David Wagner, Randi Thomas, and Eric Brewer Computer Science Division University of California, Berkeley For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: [email protected] 4. WWW URL: http://www.usenix.org A Secure Environment for Untruste d Help er Applications Con ningtheWilyHacker Ian Goldb erg David Wagner Randi Thomas Er ic A. Brewer fiang,daw,randit,[email protected] University of California, Berkeley cious programs to spawn pro ce ss e s andto read or Ab stract wr iteanunsusp ecting us er's le s [15,18,19,34,36]. Whatisnee ded in thi s new environment, then, i s Manypopular programs, suchasNetscap e, us e un- protection for all re source s on a us er's system f rom trusted help er applications to pro ce ss data f rom the thi s threat. network. Unfortunately,theunauthenticated net- workdatathey interpret could well have b een cre- Our aim i s tocon netheuntrusted software anddata ated byanadversary,andthehelp er applications are by monitor ingand re str ictingthe system calls it p er- 1 usually to o complex to b e bug-f ree. Thi s rai s e s s ig- forms. We builtJanus , a s ecure environment for ni cant s ecur ity concer ns. Therefore, it i s de s irable untrusted help er applications, bytaking advantage to create a s ecure environmenttocontain untrusted of the Solar i s pro ce ss tracing f acility. Our pr imary help er applications. Wepropose toreduce therisk goals for the prototyp e implementation includese- of a s ecur ity breachby re str ictingthe program's ac- cur ity,versatility,and con gurability. Our proto- ce ss totheoperating system. In particular, weinter- typeismeanttoserve as a pro of-of-concept, andwe cept and lter dangerous system calls via the Solar i s b elieveourtechnique s may havea wider application. pro ce ss tracing f acility. Thi s enable d us to build a s imple, clean, us er-mo de implementationofa secure environment for untrusted help er applications. Our 2 Motivation implementationhas negligible p erformance impact, and can protect pre-exi stingapplications. 2.1 Thethre atmodel Before we can di scuss p oss ible approaches tothe 1 Intro duction problem, wenee d tostart by clar ifyingthethreat mo del. Webbrows ers and .mailcap le s makeit Over the past s everal years theInter net environment convenient for us ers to view information in a wide has change d drastically. Thi s network, whichwas var iety of formatsbyde-multiplexingdocumentsto once p opulate d almost exclus ively bycooperatingre- help er applicationsbasedonthedocumentformat. s earchers whoshare d trusted software anddata, i s For example, when a us er downloads a Postscr ipt now inhabited bya much larger andmoredivers e do cument f rom a remotenetworksite, it may b e group that include s pranksters, crackers, andbusi- automatically handle d by ghostview. Since that ne ss comp etitors. Since the software anddata ex- downloaded data could b e under adversar ial control, change d on theInter net i s very often unauthentic- it i s completely untrustworthy. We are concer ned ate d, it could eas ily have b een created byanad- thatanadversary could s endmalicious datathatsub- versary. vertsthedocument viewer (through someunsp eci e d s ecur ity bug or mi sfeature), compromi s ingthe us er's Web brows ers are an increas ingly p opular tool for s ecur ity.Therefore weconsider help er applications retr ievingdatafromtheInter net. They often rely untrusted, andwishto place them outsidethehost's on help er applications to pro ce ss var ious kinds of trust p er imeter. information. These help er applications are s ecur ity- cr itical, as they handle untrusted data, butthey are 1 Janus is theRoman go d of entrance s and exits, whohad not particularly trustworthythems elve s. Older ver- twoheads andeternally kept watchover do orways andgate- ways to keep out intruders. s ions of ghostscript, for example, allowed mali- We b elievethatthisisaprudentlevel of para- thesadtaleofthe sendmail \bug of themonth" noia. Manyhelp er programs were initially envi- [1,2,3,4,8,9,10,11, 12, 13,14,16]. In anyevent, s ione d as a viewer for a f r iendly us er andwere not attemptsto build s ecur ity directly intothemany de s igne d withadversar ial inputsinmind. Further- help er applications would require each program to more, ghostscript implements a full programming be considere d s eparately|not an easy approachto language, with completeaccesstothe le system; get r ight. For now, wearestuckwithmanyuse- manyother help er applications are also very gen- ful programs which o er only minimal assurance s of eral. Wors e still, the s e programs are generally big s ecur ity; therefore whatwe require i s a general, ex- and bloated, and large complex programs are notor i- ter nal protection mechani sm. 2 ously ins ecure. Secur ity vulnerabilitie s have b een Adding new protection features into the exp os e d in these applications [15,18, 19, 34, 36]. OS: We reject thi s design for several reasons. First, it i s inconvenient. Developmentand install- ation b oth require mo di cations totheker nel. Thi s 2.2 The dicultie s approach, therefore, has little chance of b ecoming widely us e d in practice. Second, wary us ers may What s ecur ity requirements are demande d f rom a wi sh to protect thems elves withoutnee dingtheas- succe ssful protection mechani sm? Simply put, an sistance of a system admini strator topatchand outsider whohas control over thehelp er application recompile theoperating system. Third, s ecur ity- must not b e able to compromis e the con dentiality, cr itical ker nel mo di cations are very r i sky: a bug integr ity,oravailabilityoftherestofthe system, could endupallowingnew remoteattacks or al- includingthe us er's le s or account. Anydamage low a compromis e d application tosubvert theen- must b e limited tothehelp er application's di splay tire system. Thechance s of exacerbatingthe current window, temp orary le s andstorage, and asso ciated situation are to o high. Better to nd a us er-level short-live d ob jects. In other words, we ins i st on the mechani sm so that us ers can protect thems elves, and Pr inciple of Least Pr ivilege: thehelp er application so that pre-exi sting acce ss controls can s erveasa should b e granted the most re str ictive collection of backup; even in theworst cas e, s ecur ity cannot de- capabilitie s require d to p erform itslegitimatedutie s, creas e. and no more. Thi s ensure s thatthedamage a com- promised application can caus e i s limited bythere- The pre-existing reference monitor: The str icted environmentinwhich it executes. In con- traditional operatingsystem's monolithic reference monitor cannot protect against attacks on help er ap- trast, an unprotecte d Unix application thatiscom- plications directly.At most, it could preventapen- promised will have all the pr ivilege s of the account f rom whichitisrunning, whichisunacceptable. etration f rom spreadingtonew accounts once the brows er us er's accounthas b een compromi s e d, but Imp os ing a re str icted execution environmenton bythen thedamage has already b een done. In prac- help er applications i s more dicultthan it might tice, against a motivated attacker most op eratingsys- s eem. Many traditional paradigms suchasthe refer- tems f ail to preventthe spread of p enetration; once ence monitor andnetwork rewall are insucienton oneaccounthas b een subverted, thewhole system their own, as di scuss e d b elow. In order todemon- typically f alls in rapid succession. stratethe dicultyofthi s problem andappreciate thenee d for a novel solution, we explore s everal p os- The conventional network firewall: Packet s ible approaches. lters cannot di stingui sh b etween di erenttypes of HTTP trac, let aloneanalyze thedata for s ecur ity Building security directly into each helper threats. A proxy could, butitwould b e hard-pre ss e d application: Takingthings tothe extreme, we tounderstand all p oss ible le formats, interpret the could ins i st all help er applications b e rewr itten in a often-complex application language s, and squelchall s imple, s ecure form. We reject thi s as completely un- dangerous data. Thi s would makefora very complex reali stic; it i s s imply too muchworkto re-implement andthus untrustworthyproxy. them. More practically,we could adopt a react- ive philosophy, recognizingindividual weaknesses as Wetherefore s ee thenee d for a new, s imple, and eachapp ears andengineer ing s ecur itypatches one general us er-level protection mechani sm thatdoes ata time. Hi stor ically,thi s has b een a los ingbattle, not require mo di cation of exi stinghelp er applica- at least for large applications: for instance, explore tions or operating systems. The usual technique s andconventional paradigms do not workwell in thi s 2 For instance, ghostscript is more than 60,000 lines of C; situation. Wehope thatthe dicultyofthe problem and mpeg play is more than 20,000 line s long. andthepotential utility of a solution should help to application should haveaccess,ortowhichhostsit motivateintere st in our pro ject. should b e allowed toop en a TCP connection. In f act, our program oughtto b e con gurable in thi s way even on a p er-us er or p er-application bas i s.