CASPER: Compiler-Assisted Securing of Programs at Runtime GauravS.Kc,StephenA.Edwards,GailE.Kaiser,AngelosKeromytis ColumbiaUniversity,DepartmentofComputerScience 500West120thStreet,NewYork,NY10027 (cid:0) gskc,sedwards,kaiser,angelos @cs.columbia.edu (cid:1) Abstract levelcode.Thismeansthatpoorly-writtencodeornon-robust code leave a vulnerability that can be exploited with a well- Ensuring the security and integrity of computer systems de- constructed input data string or sequence of events, yielding ployedontheInternetisgrowingharder.Thisisespeciallytrue administrative-levelaccesstotheattacker. inthecaseofserversystemsbasedonopensourceprojectslike Weareconsideringtwokeyissues:preventingthecompro- Linux, Apache, Sendmail, etc. since it is easier for a hacker miseofserversoftwarebydetectinganattempttocircumvent togetaccess tothebinaryformat of deployedapplications if thenormalcontrolflowofprogramexecution[1]andlimiting the source codeto the software is publiclyaccessible. Often, the applicability of a successful attack on other servers run- havinga binary copyof an application program is enough to ningthesamesoftware.Introducingrandomizedstructureand helplocatesecurityvulnerabilitiesintheprogram.Inthecase instruction ordering as part of software compilation is suffi- oflegacysystemswherethesourcecodeis notavailable,ad- cienttohelpachieveenoughdiversityingeneratedbinariesso vancedreverse-engineeringanddecompilationtechniquescan that a single successful attack on a given instance cannot be beusedtoconstructattacks. replicatedelsewhere. This paper focuses on measures that reduce the effective- WedescribethepopularstacksmashingattackinSection2, ness of hackers at conductinglarge-scale, distributedattacks. mentionsomealready-proposedtechniquesforcircumventing The first line of defense involves additional runtime checks itinSection3,presentanewtechniqueinSection4,propose thatareabletocounteractthemajorityofhackingattacks.In- some additional ways to further modify executables in Sec- troducing diversity in deployed systems to severely diminish tion5,andconcludewithadiscussionoffutureworkinSec- the probability of propagation to other systems helps to pre- tion6. vent effective attacks like the DDOS attack against the DNS rootserversinOctober21,2002. 2 Attacktechniques:Stacksmashing 1 Introduction Although code pages are read-only by default on the Intel Internet servers are increasingly at risk of being broken x86architecture,codeplacedindatamemorycanbeexecuted into.Wormscomprisethemajorityofattackmethods against freely,makingitdifficulttodetermineiftheprocessorisexe- such systems [5]. This is different from virus and Trojan cutingforeigncodeinjectedbyanattack. horseattacksthatarecommonlypropagatedviaautomatically- The stack smashing technique, the most widely used form executingcodesentasemailattachments.Inthegeneralcase, ofhacking,exploitsthefactthatthex86doesnotdistinguish asuccessfulattackonaserversystemismoredangerousthan betweenreadandexecuteaccessesofdatamemorypages.This a break-in onapersonalcomputersimplybecauseof the po- techniqueinvolvesoverflowingastackbuffer,resultinginthe tential for there being more confidential data. For instance, injectionofarbitrarycodeinthebuffermemoryonthestack. breakingintoanAmazon.comservermightprovideaccessto Theprocessoristhenmadetoexecutethiscode,whichoften creditcarddataforalargenumberofcustomers.Hackershave endsupyieldingrootaccesstothehacker. awidearrayoftoolssuchasdisassemblers,decompilers,and 2.1 AlephOne’sSmashingtheStackforFunandProfit network monitors that enable them to constantly probe soft- ware applications to detect security vulnerabilities, e.g., by AlephOne[1]providesadetailedwalkthroughofhowtoex- reverse-engineeringthebinaryimagesofcompiledapplication ploitastackbuffervulnerabilitytobothinjectattackcodeand programs.Itismucheasiertoconstructattacksthatcancom- tooverwrite thereturnaddress of thefunctiontopointto the promisethesevulnerableapplicationsifonehasaccesstothe startingaddressofthisinjectedcode.Hesuggestswaystoin- sourcecodeoftheapplication. crease the chances of successfully hacking a system by ap- These vulnerabilities are generally the result of program- proximatingthereturnaddressoftheinjectedcodebypadding ming bugs, misconfiguration, library bugs, operating system thebeginningoftheinjectedcodewithno-opinstructionsand changes,andespeciallytheabsenceofarrayboundschecking approximating the actual position of the return address rela- on the size of input being stored in a buffer array for unsafe tivetothatofthevulnerablebufferbycopyingtheaddressof languages such as C or C++. This is an unfortunate byprod- the injected code over a range of locations so that the return uct of programming languages that produces fast system- addresslocationiscovered. 1 Report Documentation Page Form Approved OMB No. 0704-0188 Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number. 1. REPORT DATE 3. DATES COVERED 2002 2. REPORT TYPE 00-00-2002 to 00-00-2002 4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER CASPER: Compiler-Assisted Securing of Programs at Runtime 5b. GRANT NUMBER 5c. PROGRAM ELEMENT NUMBER 6. AUTHOR(S) 5d. PROJECT NUMBER 5e. TASK NUMBER 5f. WORK UNIT NUMBER 7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION Columbia University,Department of Computer Science,500 West 120th REPORT NUMBER Street,New York,NY,10027 9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S) 11. SPONSOR/MONITOR’S REPORT NUMBER(S) 12. DISTRIBUTION/AVAILABILITY STATEMENT Approved for public release; distribution unlimited 13. SUPPLEMENTARY NOTES 14. ABSTRACT see report 15. SUBJECT TERMS 16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF 18. NUMBER 19a. NAME OF ABSTRACT OF PAGES RESPONSIBLE PERSON a. REPORT b. ABSTRACT c. THIS PAGE 6 unclassified unclassified unclassified Standard Form 298 (Rev. 8-98) Prescribed by ANSI Std Z39-18 The hacker can have the injected code carry out various 3.4 Programshepherding tasks,e.g.,stealconfidentialinformation,mutilatedatastores, Kiriansky et al. [11] propose a policy-driven mechanism for defacewebsites,etc.Often,ahackerwillleaveabackdoorthat closely monitoring and dynamically controlling the flow of willenablehimtoreturntothesystematafuturepoint,e.g., program execution. They define different default and cus- byinsertingaroot-uidentryin/etc/passwd.Usually,the tomizable security policies for code based on the nature of injected code is used to spawn a shell that gives the attacker its origin, whether it was loaded from the local file system, administrativeaccess. generatedbytherunningprogramitself,orifitself-mutated. 3 RelatedWork Their system is integrated into an interpreter, which enables thesandboxedcheckingofrunningapplicationsandmonitor- 3.1 Softwarediversity ing of their control-flow. While the functionality of this ap- proach is attractive, the fact that it is interpreted makes for Forrest et al. [6] discuss the advantages of bringing diversity significantoverhead. into computer systems, and likens the effects to that which diversity helps cause in biological systems. They observed 3.5 Libsafeandlibverify how the lack of diversity among computer systems can fa- cilitate large-scale replication of exploits due to the identi- The libsafe project [2] replaces potentially dangerous stan- dardlibraryfunctionswithsaferimplementationsthatbounds- cal weakness being present in all instances of the system. checkparameters.Throughcleverchoicesofalgorithms,run- Someideasarepresentedregardingusingrandomizedcompi- lationtointroducesufficientdiversityamongsoftwaresystems ninglibsafecanactuallydecreaseprogramruntimes.Thisap- proachremovesallweaknessesduetotheabsenceofbounds to severely hamperlarge-scale spreading of exploits. Among these,theonesmostrelevanttothispaperinvolvetransforma- checking in standard library functions such as printf, etc. Thelibsafesystemisinstalledasadynamicallyloadedlibrary tionstomemorylayout. thatinterceptscallstopotentiallyunsafestandardlibraryfunc- 3.2 CycloneandBoundsCheckingforCArrays tions. The main disadvantage of libsafe is that it will fail to protectagainstvulnerabilitiesinuser-definedornon-standard In theCycloneproject, Jim et al. [9]propose a dialect of the librarycode.Also,ifanapplicationiscompiledwiththestan- C programminglanguage thathas built-insupport forasafer dard library function statically linked in, the libsafe mecha- pointermodel, morestatic type checking,etc. This program- nismwillbecompletelyineffective. ming language is designed to generate an executable as effi- The related libverify project [2] works by maintaining a cientasthatfromCwhilereducingthelikelihoodofproducing copyofallobjectcodeontheheap,andexecutingthatinstead unsafeprograms.ThefactthatCycloneusesadifferentmem- of havingthe processorfetchand execute code from the text orymodelforitsinternaldatastructuresrendersitincompati- segment. This permits the libverify system to run checks at blewithexistingsystemswritteninCorC++. load time, and also insert mechanisms for runtime checking Jones and Kellys [10] patch to the GCC compiler adds oftheexecution,primarilydealingwithverifyingafunctions bounds-checkingforpointersandarrayswithoutchangingthe returnaddressbeforepassingcontroltothefunctioncaller. memory model used for representing pointers. This helps to preventbufferoverflowexploits,butatanunacceptablecost— 3.6 StackGhost allindirectmemoryaccessesarechecked,greatlyslowingpro- Frantzen and Shuey’s StackGhost [7] is implemented as a gramexecution. kernel patch for OpenBSD for the Sun SPARC architecture, whichhasmanygeneral-purposeregisters.Theseregistersare 3.3 StackGuardandMemGuard usedbytheOpenBSDkernelforfunctioninvocationsas reg- ImplementedasacompilerpatchtoGCC,Stackguard[4]in- ister windows. The return address for a function is stored in sertsacanary wordrightbeforethereturnaddress inafunc- a register instead of on the stack. As a result, applications tion’sactivationrecordonthestack.Whiletryingtooverwrite compiled for this architecture are more resilient against nor- the return address, a stack smashing attack would also over- mal input string exploits. However, for deeply nested func- writethecanaryword.Thevalueofthecanarywordischecked tion calls, the kernel will have to perform a register window just before the function returns, and the program prints an switch, which involves saving some of the registers onto the error message and halts if it has changed. This circumvents stack. StackGhost removes the possibility of malicious data simple-minded stack-smashing techniques, although bypass overwritingthestoredregistervaluesbyusingtechniqueslike techniqueshavealreadybeendeveloped[3]. write-protectingorencryptingthesavedstateonthestack. MemGuard [4]makes thelocationof the returnaddress in 3.7 StackShield thefunctionprologueread-onlyandrestoresituponfunction return,effectivelydisallowinganywritestothewholesection StackShield[12]isanotherGCCextensionwithanactivation ofmemorycontainingthereturnaddress.Itpermits writes to record-basedapproach.Theirtechniqueinvolvessavingthere- over locations in the same virtual memory page, but greatly turnaddresstoawrite-protectedmemoryarea,whichisimper- slowsthembecausetheymustbehandledbykernelcode.The vioustobufferoverflowswhenthefunctionisentered.Before largeoverheadsoincurredmakesthistechniqueimpractical. returningfromthefunction,thesystemrestorestheproperre- 2 foo: foo: turnaddressvalue.Thismethodisverygoodatensuringthat pushl %ebp pushl %ebp theflowofcontrolisneveralteredviaafunction-return.How- movl %esp,%ebp movl %esp,%ebp ever,itcannotdetectthepresenceofanydatamemorycorrup- subl $24,%esp subl $24,%esp tion,andhenceissusceptibletoattacksthatdonotrelysolely xorl $14351054,4(%ebp) ...body ...body onthereturnaddress. xorl $14351054,4(%ebp) movl %ebp,%esp movl %ebp,%esp 4 OurApproach popl %ebp popl %ebp OpensourcesoftwareisverywidelydeployedontheInternet. ret ret (a) (b) Sincethesameversionofthesoftwareisrunningonmillions of computers, a single attackthat can exploit a given vulner- Figure1:(a)Originaland(b)XOR-patchedfunctionentryand ability will be able to overcomeall instances of the software exit code. The value XORed with the return address is cho- without requiring any extra work on the part of the hacker. senrandomlyeachtimetheprogramiscompiled.Ifanattack Thisisoneofthereasonsthathackershavebeensoeffective managedtochangethereturnaddressat4(%ebp),thesecond at breaking intosoftware systems andconductinglarge-scale xorlinstructionwouldcorruptit,mostlikelycausingthepro- DDOS attacks [8]. The more determined hacker can always cessortojumptoanillegallocationandterminatetheprogram. use reverse-engineering tools on the binary images of com- piledapplicationprogramstohuntforvulnerabilities.Having access to thesource makes thejobeasier, sinceonecan now Guard methods are equallyeffective at ensuring the integrity search for strings like printf or syslog, which often re- of the return address. Both methods guarantee (somewhat) vealpossibleweaknesses. a valid return address before returning control to the calling We plan to make each binary executable of a particular function.However, it is possibleto construct anattack string server program change dynamically so that a successful at- that can successfully ’tiptoe’ over the current canary word tackononecopyisnoteffectiveonanyother,orevenonthe and leave it untouched, e.g., by incorporating the 32-bit ca- sameoneafewhourslater.Thisavoidstheproblematicmono- nary value in the attack string, thus completely circumvent- cultureofbroadly-deployedapplicationsbasedonidenticalbi- ingStackGuard’sdefensemechanism[3].Amajoradvantage naries,eachcontainingthesamevulnerabilities.Byeliminat- ofusingtheXORedreturnaddressovertheStackGuardtech- ing this wide-scale mono-culture, we can significantly mini- niqueisthatitishardertoachievethesamesinceonewould mize the impact and success of large-scale security attacks. needtoreadthe32-bitvalueusedfortheXOR—thisvalueex- Therearenumerouswaysofmodifyinganapplicationatboth ists onlyinthe code memory,as opposedtothecanaryword thesourceandbinarylevels.Ineithercase,theprogrammust whichdoesexistindatamemory. continuetobehaveidenticallyatahighlevel. A sophisticated attack on an XOR-fortified system would Ensuringthatasuccessfulattackcannotexploitagivenvul- needtoanalyzethebinarylayoutoftherunningprogramand nerability in multiple installations of the same version of an extractenoughinformationabouttheXORvalueusedtosuc- application is helpful for reducing the number of collabora- cessfully construct an attack on the system. The actual input tive, distributed attacks. However, it is important to fortify data sequence that is used to overrun the buffer needs to be server applications from singular attacks as well. Many au- modifiedsothatthefunctionepiloguewillendupXORingitto thors [4, 7, 12] observe most successful attacks exploit au- makeitpointtotheinjectedcode.Thistaskcanbemadeharder tomatic buffers that are allocated in a function’s activation byusingcustom32-bitvaluesforeachfunction,andpossibly record.Itisthereforepossibletofendoffthemajorityofsecu- eachinvocationofeachfunction.Thisway,theattackercannot rityattacksbysecuringtheactivationrecordduringtheexecu- usestaticanalysestoconstructaninputsequence. tionofthefunction. Our approach is less favorable than the StackGuard tech- niquewithregardstoguaranteedhaltingortheprintingofan 4.1 XOR:ASimpleMaskingTechnique informationalmessageupondetectionofanattack.However, WehaveimplementedasimplepatchtoGCC,similartoStack- our technique is a muchsimpler,smaller way to detect stack Guard’s approach to using the function activation record to smashingattacks.Onlytwomachineinstructionsareaddedto detect and handle a security breach. However, instead of in- eachfunctionbody:onefortheXORatthefunctionprologue, troducing a canary word entry in the activation record, we and one at the epilogue. This results in a significantly faster obfuscate the return address at the top of the stack frame by executionforfunctioninvocations.Infact,aprogramthatin- XORing it with a randomly-chosen 32-bit value. Just before vokesasmallfunctioninatightloopcaneasilyenduprunning thefunctionreturns,weXORthereturnaddresswiththesame significantlyslowerwhencompiledwiththeStackGuardpatch 32-bitvaluetoreturnittoitsoriginalvalue.Ifanattackerhas thanwithourapproach,asweshowinSection4.2. successfully overrun a buffer and modified the return value, Itmightbearguedthatwecouldattempttosalvagethepro- thisfinalXORwillcorruptit,mostlikelysendingtheprogram gramstateorevenlettheapplicationshutdowncleanly.How- countertoanillegaladdressandcausingasegmentationfault ever,thereareverylimitedguaranteesthatcanbemadeabout thathaltstheprogram.Figure1illustratesthecodethispatch thememoryandinternaldatastructuresafterasuccessfulstack insertsinafunction’sprologueandepilogue. smashingattack.Inmostcases,itisacceptabletohavethepro- Forstacksmashingattacksalone,boththeXORandStack- gramcrash,andperhapsgenerateacorefileintheprocessof 3 #define LIMIT 500000000 code XOR StackGuard i++ 0% 0% static int i = 0; voidinc() 101% 125% void inc_global() { i++; } voidint(int*) 13.1% 69% void inc_ptr(int *i) { (*i)++; } intinc(int) 11.5% 80% int inc_r_val(int i) { return i+1; } Table1:Comparisonofexecutiontimeoverheadbetweenthe int main(int argc, char *argv[]) { switch (atoi(argv[1])) { XORandStackGuardtechniques,showingtheexecutiontime case 0: overhead of XOR is noticibly lower. (StackGuard numbers while (i < LIMIT) i++; fromCowanetal.[4]) break; case 1: while (i < LIMIT) inc_global(); Program Executiontime Exec.timewithXOR break; gcc 45m2.0s 45m3.5s case 2: ctags 12.902s 15.555s while (i < LIMIT) inc_ptr(&i); break; Table2:Comparisonofexecutionspeeds.TheXOR-protected case 3: while (i < LIMIT) i = inc_r_val(i); gccexecutabletookalmostthesametime;theXOR-protected break; ctagsexecutable(runon227klinesofinput)took20%longer. } return 0; } modifiedgcc-2.95andourXOR-techniquetocompileour Figure2:Programusedinmicro-benchmarks. patchedversionofgcc-2.95.Italsoshowstheresultsrun- ningthectagsprogramonthesourcecodeforvim6.1text editor. These results show our XOR-based approach requires doingso.This corefile canbeusedat apost-execution anal- littleoverhead. ysis phase to determine the exact location and nature of the vulnerability and the attempted exploit. However, in certain 4.3 Provisionsfordebugging cases,itwouldbebettertoletthecompromisedprogramcon- Beingabletodebugsuch“fortified”applicationsisequallyim- tinue execution so that the attackers intentions can be moni- portantassecuringtheminthefirstplace.Mostofthesetech- tored.Obviously,thecorruptedapplicationshouldbeallowed niquesthatattempttoputoffanattackeralsomakeitharderfor to continue only after dynamically sandboxing the program. adebuggerlikeGDBtoproperlyextractruntimeinformation Iftheapplicationishalted,itcanberecompiledimmediately abouttheexecutionofaprogram;forexampleStackGuardsin- withadifferentbinarysignature,andberestarted.Thiswould troductionofthecanarywordchangesthestacklayout.When beusefulwhendealingwithapplicationswithhighavailability using a pre-defined single XOR value, it is possible to hard- requirements,e.g.webservers,databaseservers. codethisvalueintogdbdirectlyandhaveitcomputethereturn 4.2 Experimentalresults addressforanactivationrecordduringtheexecutionofafunc- tion. This 32-bit value is also needed to help reconstruct the ExperimentswiththeXOR techniqueproducedverypromis- callingsequence byfollowing the dynamic chain of function ingresults.We wereabletodetectandthwarta simplestack invocations.However,usingdifferent32-bitvaluesfordiffer- smashingattackwithnegligibleeffectontheexecutiontimeof ent functions to achieve increased security means that it be- thegeneratedcode. comesincreasinglyhardertobeabletouseGDBwiththepro- We ran some micro-benchmark tests identical to those of ducedexecutable. StackGuard [4] involving different ways of incrementing an UsingindividualXORvaluesforeachfile(orfunction)gen- integeralargenumberoftimes(Figure2shows theprogram eratedbythecompilermakesitwasnecessarytoenableapro- weused).Table1showsthatourXOR-techniquefaredmuch gramlikegdbtoaccessthisinformationatruntime.Weencap- betteragainst theunmodifiedinstallationofgcc-2.95than sulatethissetofXORvaluesinastaticfunctionintheoutput StackGuarddidagainstunmodifiedgcc-2.7.2.3(although file,whichgdbcandynamicallyusetointerprettheperceived thetwopatcheswereappliedtodifferentrevisionsofgcc,we return-addressforagivenfunction,yieldingthetruereturnad- believe this comparison is valid). The only significant slow- dressforthefunction.Adifferentapproachinvolvesperform- down(afactorof 2)inourapproachwasseenwiththesec- ingtransformationsonthefunctionssothateachencapsulates (cid:0) ondtestwhereazero-argumentfunctionisusedtoincrement itsownXORinformation.Obviously,allthesetransformations a global variable. However, this is the worst-case scenario havetoappeartransparenttogdb,whilestillkeepingtheXOR caused by the minuscule-sized function body. The overhead informationencapsulated,andsafelyhiddenfromtheprogram approaches zero as the complexity and size of the functions runtime. increase. 5 OtherTechniques Wealsoransomemacro-benchmarkstocomparetheeffects of our XOR-technique on the execution of real-world appli- In this section, we describe a few additional defense mecha- cations. Table 2 shows the execution time for usingboth un- nisms against stack smashing techniques. Each of these may 4 notseemthatpowerful inisolation.Howeverwe believethat anynear-totalguaranteesagainstpossiblebreak-ins,itisnec- byusingdifferentcombinationsoftheseindividualtechnolo- essary to consider other infrequent forms of security attacks gies,wewillbeabletoachieveahighdegreeofbinarydiver- andtheirrelatedexploits.Weneedtoconsiderthepatternsof sitybetweendifferentinstallationsofthesamesoftware. variousotherattacktechniqueslikeheap-smashingtechniques andfunctionpointeroverwriting.AlanguagelikeC++withan 5.1 Automaticgarbagecollectionofthestackframe accessibletableoffunctionpointers(virtualtable)alsoopens Stacksmashingattacksmakeuseofautomaticbuffersthatare upcompiledcodetoattacksthatattempttocorruptthepointer allocatedon the stack frame forthe duration of the function. tables. Strongly-typed languages that heavily depend on the This section of memory need not contain validdata after the type-safetypropertiesofthelanguagearevulnerabletoattacks functionreturns.Hence,thecompilercaneasilyinsertacallto thatcancircumventthetype-checkingmechanismssuchasil- memsetattheendofthefunctionepilogue.Thiswillhavethe legalaccesstoprivateencapsulateddataviatype-spoofing.Al- effect of erasing the contents of all local variables or buffers mostallprogramminglanguageshavesomeformofdynamic thatcouldpossiblycontainmaliciouscode. memory management schemes (manual or automatic, with a garbagecollector).Ahackermightbeabletooverwriteheader 5.2 Heap-basedactivationrecords informationlikethemeta-datausedbymallocinthedynam- Nestedfunctioninvocationsresultintheactivationrecordsfor icallyallocatedblockstocorruptthedatastructuresrelatedto the functions being adjacent to each other in the data stack. thememorymanagementsubsystems.Ourcurrenttechniques Thismakesitpossibleforabufferoverflowinadeeply-nested willnotbeabletodetectattackslikethesesincethereturnad- function to overwrite the return address, or carry out other dressforthefunctionwillbeleftintact,withthedamagebeing memory-corrupting operations for a different function, mak- doneelsewhere. ingithardertohavedetectionandpreventativesecuritymech- Allofthedefensemechanismsdiscussedhereinvolvesome anisms.Allocatingeachactivationrecordindynamicallyallo- speedandsizeoverhead.Itmightbepossibletohavethecom- catedheapmemoryinsteadofthestackshouldhelpavoidthis pilerselectivelyinsertprecautionarymeasures whengenerat- problem. The above-mentioned notion of automatic garbage ingcodeforfunctions. Simplerfunctionsthatobviouslycan- collectionofausedstackframetiesinverywellwithhaving not be attacked may not need to be fortified. However, it is activationrecordsontheheap. possiblethatavulnerabilityinonepartoftheprogramexecu- 5.3 Randomizingmemorylayouttoachievediversity tion can be used to corrupt memory data in a different loca- tion.Forinstance,ahackercouldreplacethereturnaddressof Theideaspresentedinthis subsectionare verysimilarinna- asafeframefromaninnervulnerableframewithoutaffecting turetothememorylayouttransformationsproposedbyForrest theinnerframeitself.Randomly-spacedframescanbeusedto etal.[6].Randomly-spacedactivationrecordscanbeusedto so that the return address for any given adjacent or ancestor counteract a stack smashing attempt by reducing the chance frame will not be at a statically determinable location. A lo- thatthemodifiedreturn-address valuewillsuccessfullypoint cal usercould,however,bypass this by inspecting the binary totheinjectedcode.Anothermajoradvantageofthisapproach imageoftheprogrambeingexecuted. is that it makes it even harder for an exploit in one function frametooverwritedatainacallingfunction’sstackframefur- The XOR approach is the main technique we have exper- therupthedynamicchain. imented with to date, and the other techniques discussed in Section5areonlythefirstinaseriesofextensionsbeingcon- 5.4 Diversificationwithinasinglesystem sideredthatwouldresultindiversifyingbinariesandthwarting These security techniques can be repeatedly used to achieve variousclassesofattacks.Thereareopenissuesregardingthe diversitywithinthesameinstallationofserversoftware.Car- security of the whole system: using our current technique to rying out recompilation of the applications fairly frequently compileapplicationcodewhileusingoriginallibrarieswould shouldhelpreducetheriskofbeingattacked.Thisisbecause still leave us with a vulnerable system. We plan to study there is very little likelihood of an attacker being able to lo- loader-andlinker-basedapproachesthatmightaddressthese- cate a weakness and successfully devise an attack scheme to curing of non-open source libraries and legacy applications. exploit that vulnerability before the next scheduled recompi- Anotheradvantageofintroducinglate-bindingofthesecurity lation. Service downtime can be avoided by using a failover mechanismisthatthecompiledunitswouldnotexposesecu- strategyto incrementally migrate fromthe old version of the ritydetails.Itisalsoimportanttoexaminehowourcurrentand server binary to the new one every time one needs to switch proposed techniques would interact with optimizations, with servers. However, there are disadvantages to this approach different kinds of hardware architectures, such as PowerPC, since it requires additional time and processor resources for SPARC,MIPS,andembeddedprocessorslikeARM.Someof theextrarecompilations. the techniques that we will implement may not be portable acrossallarchitectures,somachine-specificmethodswillalso 6 FutureWork beconsidered.Finally,weareinterestedinexamininghowvar- Being able to secure a deployed system against the major- ioussource-levelandpeepholeoptimizationtechnologiescan ity of existing (and future) attacks might be sufficient for a beappliedtoimprovingsecurityasopposedtojustoptimiza- server system in the general case. However, in order to give tion. 5 7 Conclusion References Computersystemhackingisbothanartformandascienceas [1] Aleph One. Smashing the stack for fun and profit. muchasvirtuallyanyotherfieldofcomputerscience.Identi- Phrack,7(49),1996. fying vulnerabilities in a program application is a fairly dis- [2] A.Baratloo,N.Singh,andT.Tsai. Transparentrun-time ciplined field that requires high ability and lots of ingenuity. defenseagainst stacksmashingattacks. InProceedings No absolute guarantees can be made about whether a soft- ofthe2000USENIXAnnualTechnicalConference,June ware system will be completely hack-proof It is hoped that 2000. this research will derive a technology that is a economically and practically feasible solution to maintaining the security [3] Bulba and Kil3r. Bypassing StackGuard and Stack- andintegrityof an application system. Thereare expected to Shield. Phrack,5(56),May2000. beanumberoftradeoffsthatonewouldneedtoconsidersuch as theeffectoftightersecurityonprogramexecutionandthe [4] C. Cowan, C. Pu, D. Maier, H. Hinton, J. Walpole, likelihood of generating more false positives for attacks de- P. Bakke, S. Beattie, A. Grier, P. Wagle, and Q. Zhang. tected. The ultimate goal is to provide a set of customizable Stackguard: Automatic adaptive detection and preven- security mechanisms that a user can choose to best fit her tionofbuffer-overflowattacks. InProceedingsofthe7th needs,thushelpingmakethesystemsecurewhilestillleaving USENIXSecuritySymposium,Jan.1998. it usable. Widespread adoption of a given technique requires [5] M.EichinandJ.Rochlis.Withmicroscopeandtweezers: anumberoffeatures:simplicityinincorporation,backwards- An analysis of the internet virus of november1988. In compatibility with existing systems, imperceptible effect on Proceedings of IEEE Computer Society Symposium on compilationandexecutionspeed,andsoon. SecurityandPrivacy,1989. GCCisastable,well-constructed,well-knownandwidely- accepted compiler technology. Implementing our research [6] S.Forrest,A.Somayaji,andD.Ackley.Buildingdiverse ideas on top of this open source compiler system has obvi- computersystems. InHotOS-VI,1997. atedtheneedtoinvestheavilyinbuildingaworking,compre- hensivecompilersystemfromscratch.Useofsuchtoolswill [7] M. Frantzen and M. Shuey. StackGhost: Hardware fa- enablefurtherresearchonourresults. cilitatedstackprotection. InProceedingsoftheUSENIX SecuritySymposium,2001. Acknowledgements [8] K. J. Houle, G. M. Weaver, N. Long, and R. Thomas. Wewouldlike tothank AlfredAho for hisinsightfulcomments on Trendsindenialofserviceattacktechnology. Technical theapproachdescribedinthispaper,andSpirosMancoridisandVas- report,CERT,2001. silisPrevelakisfromDrexelUniversityforusefuldiscussionsonvul- http://www.cert.org/archive/pdf/DoS trends.pdf. nerabilitiesandothersecurityissuesrelatedtoopensourceprojects. Kaiser’sProgrammingSystemsLaboratoryisfundedinpartbyDe- [9] T.Jim,G.Morrisett,D.Grossman,M.Hicks,J.Cheney, fenseAdvancedResearchProjectAgencyunderDARPAOrderK503 and Y. Wang. Cyclone: A safe dialect of C. In Pro- monitoredbyAirForceResearchLaboratoryF30602-00-2-0611,by ceedings of the USENIX Annual Technical Conference, NationalScienceFoundationgrantsCCR-02-03876,EIA-00-71954, Monterey,California,June2002. andCCR-99-70790,andbyMicrosoftResearch.Keromytisisfunded inpartbyDARPAandtheAirForceResearchLaboratory,AirForce [10] R.W.M.JonesandP.H.J.Kelly.Backwards-compatible Material Command,USAF,underagreement numberF30602-01-2- boundscheckingforarrays andpointersinCprograms. 0537.EdwardsisfundedinpartbytheNationalScienceFoundation In Third International Workshop on Automated Debug- undergrantCCR-0133348,undertheNewYorkStateNYSTARpro- ging,1997. gram,andbyIntelCorporation. [11] V.Kiriansky,D.Bruening,andS.Amarasinghe. Secure execution via program shepherding. In Proceedings of the11thUSENIXSecuritySymposium,Aug.2002. [12] Vendicator. Stackshield. http://www.angelfire.com/sk/stackshield/. 6