Comprehensively and efficiently protecting the heap - PDF document

 Minos[14],whichtagseachdataitemwithanintegritybitthatissetto’1’ifthedatacomesfromreliablesources.Anattackisdetectedwhenadataitemwithintegritybitof’0’isusedforachangeincontrolow.Programshepherding[16]isatechniquethroughwhichpoliciesregardingcontrolowtransfercanbespec-edandenforced.Non-executableheap,dynamictracking,Minos,andprogramshepherdingtrytopreventthelaststageofanattack(theseizedstage),andassumethatanattackreliesoncontrolhijack.Theyfailwhentheattackdoesnotrelyoncontrolowhi-jack.Forexample,non-controlattacksdonotrelyoncontrolcations,yethaverecentlybeendemonstratedtobeaspow-erfulascontrol-owattacks[6].Inaddition,non-executableheapalsofailsforcontrol-owattacksthatdonotrelyoncodeinjec-tion,suchasonesthatdivertthecontrolowtolibrarycode[22].Oursolutiondiffersfromnon-executableheap,dynamictracking,andMinosinthatwepreventtherststageofanattack,ratherthanlatterstages,henceweuseminimalassumptionsonhowlatterstageswillbecarriedout,regardlessofwhetheranattackreliesoncodeinjection,control-owornon-controlmodications.Inaddi-tion,comparedtodynamictrackingandMinos,oursolutiondoesnotrequirenewhardwaremechanisms.Storingpointersencryptedinthemainmemoryhavebeenpro-posedasasoftwareapproachinPointGuard[7]andrecentlyasahardwareapproachforstackprotection[19].Thecompilerorbi-naryrewriterisrequiredtoidentifytypeinformation,andapplyencryption/decryptiononpointeraccesses.However,withoutsac-cinglanguagecompatibility,accuratelyidentifyingpointerac-cessesisdifcultinCprogramsduetolackoftypeinformation.Forexample,manyC-languagefeaturesdependonfunctionswithuntypedbuffers(e.g.,)ortakeuntypedparame-ters(e.g.,),makingitdifculttogetanaccuratetypeinfor-mation.Also,existinglibrarycodedoesnotalreadycontaintypeinformation.Furthermore,withoutextrahardwareforencryption,encrypting/decryptingeachpointerforeverywrite/readincursahighperformanceoverhead.Finally,futureheapattacksmaynotrelyoncorruptingpointersbutotherpartsofmeta-data.Oursolu-tiondiffersfrompointerencryptioninthatoursolutiononlyneedscationstotheallocation/deallocationroutines,iscompatiblewithexistingusercode,andprotectsallheapmeta-datastructures(notjustpointers)againstcorruption.Obfuscationtechniquesforheapprotectionandbeyondhavealsobeenproposed[5,20,31]withagoalofmakingthead-dressspacelesspredictableandincreasestheeffortoftheat-tackerstomakeasuccessfulattack.TransparentRuntimeRan-domization(TRR)[31]andAddressSpaceLayoutRandomization(ASLR)[20]aresoftwaretechniquesthatrandomizethestartingaddressofvarioussegments(heap,stack,BSS,etc.)anddynamiclibrarycodeswhenaprogramisloaded[31].AlthoughTRRandASLRincreasethedifcultyofattacksthatinvolvemorethanonesegment,theycannotprotectagainstattacksthataresolelycarriedoutwithintheheapsegment.Addressobfuscation[5]isanothertechniquethat,inadditiontorandomizingthestartingaddressofvarioussegments,alsointroducesrandompaddingbetweenconsec-utiveheapchunkstomaketheheaplayoutlesspredictable.How-ever,recentworkbyShachametal.[13]showsthatrandomizationimplementationson32-bitarchitecturessufferfromlowentropyof16-20bits,whichdoesnotgivesufcientprotectionagainstde-terminedattackers.Additionally,inrealisticimplementations,theamountofpaddingbetweenchunksarelimitedtotheminimumof25%oftherequestedallocationsizeandathresholdvalue(e.g.128bytes),toavoidexcessivefragmentationoftheheapspace.Withamaximumof128-bytepadding,thereisonly =16paddingsizesbetweentwoconsecutive8-bytealignedheapobjects,whichisinsufcientagainstdeterminedattackers.Asaresult,webelievethataddressobfuscationcanonlybeusedforheapdata,whereattacksrequiredetailedknowledgeoftheapplication.Heapmeta-data,however,hasthesamestructureinallapplicationsthatusethesamelibrary,sotheincentivefordevisingmeta-dataattacksishigher.Asaresult,meta-dataneedsstrongerprotection.HeapServerincorporatesBhatkaretal.’saddressobfuscationtechniqueandimprovesitbyaddingrandomrecyclingofheapob-jects.Wenotethatduetotemporallocalityoptimizations,theheapmanagementlibraryoftenimmediatelyrecyclesthemost-recentlyfreedobjectforasubsequentallocation.Thisregularitymeansthatonceattackersgureoutthelayoutoftheheap,futureallocationshavepredictablelayout.Ourrandomrecyclingintroducesrandomselectionamongeligiblefreeheapobjectswhenallocationisre-quested.Thisprotectionmakesitharderforanattackertooutthetargetlocationtooverwritethroughouttheprogramexecu-Concurrenttoourwork,BergerandZornproposedDieHard[3].LikeHeapServer,DieHardemployssimilartechniquestoseparateheapmeta-datafromheapdatastorage,andappliesrandomizedpaddingbetweenheapchunks.DieHardalsoexaminesusingmul-tipleredundantinstancesofanapplicationtodetectattacks.OnemajordifferencewithHeapServeristhattheHeapServerfurtherprotectsheapmeta-databykeepingitinaseparateaddressspace,completelyavoidingapplicationvulnerabilitiesfromoverwritingit.3.HeapAttacksandProtection3.1Bug/VulnerabilityExploitationStageTheentrypointofasecurityattackisoftenexternalinputfromthenetwork.Theinputcausescertainoverwritesduetovulnerabil-itiesintheprogram.Inabufferovervulnerability,aprogramlacksbufferboundcheckingandallowsalongstringinputtoover-owandoverwriteadjacentbytesbeyondthebuffer.Inanintegerovervulnerability,asigned-integervariableusedinindexingastructureisnotcheckedforitsvalidrange.Atoo-largevaluemaybeinputandbecomesanegativenumberinthevariable,causinganaccesstoalocationbeyondthestructure’srange.Inaformatstringvulnerability,auseoffamilyoffunctionsthatacceptsfor-mattinginformationinitsstringinputmayleadtobothreadattacks.Forexample,formattokenscanrevealthecontentofthestackandpossiblyotherlocations,whiletokencausesthenumberofbytesprintedtobewrittentoalocationedinformatstringarguments,whichallowsanoverwritetoarandomlocationwiththevaluechosenbytheattacker.Notethatwhilebufferoverowsallowcontiguousoverwritestoadjacentbytes,integeroverowandformatstringvulnerabilitiesalsoallownon-contiguousoverwritesinamorerandom-accessfashion.Inadditiontovulnerabilities,aprogrammaynaturallyhavebugs,whichmanifestundercertaininputsorexecutionenviron-ment.Thebugsmaybetransformedintosecurityattacksifattack-ersknowhowtoexploitthem.Forexample,inadanglingpointerbug,astill-in-useheapchunkisincorrectlydeallocated,allowingtheheapmanagementlibrarytowriteheapmeta-datainformationtoit,causingsubsequentaccesstothechunktousecorrupteddata.Inaninvalidfreebug,aninvalidvalueisincorrectlypassedtothedeallocationroutine,resultingintheaddresspointedbythevaluetobeoverwrittenbyheapmeta-data.Inadoublefreebug,analready-deallocatedheapchunkisdeallocatedagain,causinginconsisten-ciesinthefreelistthatmaintainsdeallocatedobjects.Bugexploitsmaybeduetoactualbugsintheprogram,orbefollow-upactionsafterasuccessfulvulnerabilityexploitation.3.2ActivationStageThepreviousbug/vulnerabilityexploitationstageallowsanover-writeassociatedwiththevulnerabilitytooccur.Inmanycases,theattackerstillneedstoconvertthisinitialoverwriteintoamorepow-erfulprogrambehavioralteration.Thisisperformedinthetionstage.Theattackersmaywanttomodifycontrolowinfor- nottothestartofaheapchunkortoalocationoutsidetheheaprange.Adoublefreewillbedetectedasadeallocationtoachunkwhoseheapmeta-dataindicatesthatthechunkisalreadydeallo-cated.Attemptstodeallocatenon-heapdata(inordertooverwriteit)willalsobecaughtbecausetheHeapServerwillnotndavalidmeta-datarecordcorrespondingtotherequestedlocation.Onlydanglingpointerexploit(deallocationofastill-liveob-ject)maynotbefullyprotectedagainst.AdeallocationrequesttoavalidandliveheapobjectisalwaysacceptedbytheHeapServer.However,unlikeintraditionallibrarieswhichoverwritepartsoftheobjectwithheapmeta-datacausingdatacorruption,HeapServernevercorruptsdatawhenitupdatesthemeta-dataasaresultofthedeallocationrequest.Inthefuture,iftheobjectifnallydeal-located,HeapServerwilldetectitasadoublefreeattempt.How-ever,ifthedeallocatedchunkisrecycledbeforetheactualdealloca-tionoccurs,twoheapobjectsmayincorrectlyshareasingleobjectspace.Thismaylikelyleadtocrash,butmeaningfulexploitationbyattackersisunlikely,becauselayoutobfuscationpreventsattackersfromknowingwhichtwoobjectsaresharingthatspace.4.HeapServerDesignandImplementationHeapServerisaseparateprocessthatperformsheapmanagementonbehalfofanapplication.HeapServer’sprotectioncomesfromthreemechanisms.First,itusesanewbitmappedheapmeta-dataorganization(Section4.1)thatstoresheapmeta-dataseparatelyfromheapdata,butstillallowsfastmeta-datalookupswithlowstorageoverhead.Secondly,theheapmeta-dataismovedfromtheapplication’saddressspacetotheHeapServer’saddressspace(Section4.2).Theapplicationcommunicatesitsallocationanddeallocationrequeststhroughinter-processmessagingtotheHeapServer,whichmanagestheheapmeta-datafortheapplication.Finally,theHeapServerobfuscatestheheaplayouttomakeitcultfortheattackerstoattackheapdatawhichresidesintheapplication’saddressspace(Section4.3).4.1HeapMeta-DataOrganizationTheefciencyofheapmanagementimplementationdependsonhowtheheapmeta-dataisstoredandlookedup.Specically,itshould(1)uselittleextrastorage,(2)allowefcientlookupofthemeta-dataofachunkfordeallocationpurpose,(3)alloweflookupofthemeta-dataofachunk’sneighborsforconsolidation,and(4)allowefcientlookupofafreechunktoreuseonanallocationrequest.Ifweexpecttheaverageheapobjectsizetobelarge,wecankeepaheapobject’smeta-dataasaxed-sizenode,andnodescanbeorganizedinabinarysearchtreeorahashtable.Tolookupthemeta-dataofachunk,wecanusethechunk’saddresstosearchthetreeorindexthehashtable.However,atanygiventimethenumberofallocatedchunkscanbelarge(sometimesinthemillions),theremayalsobemanyallocations/deallocationsperunittime,andtheaveragechunksizemaybeverysmall(tensofbytes).Insuchcases,atreesearchandrebalancewouldincurlogoneveryallocationordeallocationrequest,whichisclearlynotacceptableintermsofperformance.Asearchonan-entryhashtablewouldtake(1+ whichisexpensiveunlessislarge(i.e.thehashtableislarge).Asaresult,wechoosea.Inourimplementation,everyeightbytesofheapdataareassociatedwith2bitsofmeta-data,fora3.125%spaceoverheadrelativetotheheapdataspace.Thisbit-mappedorganizationisespeciallystorage-cientwhenchunksaresmall,simpleindexing( Bit-mappedmeta-dataorganizationisstandardingarbagecollectiontech-niques[15]fortrackinganobject’sgenerationandaccesses.themeta-dataforachunk,andmeta-dataofachunk’sneighborscanbefoundincontiguouslocations. chunk is allocated chunk is allocated dFAFAd Application HeapValue bit array Figure4.Bit-mappedmeta-datainformationthatiskeptbytheHeapServer.Becausecorrectalignmentofallocatedblocksrequireseverychunktobeginatamultipleofeightbytes(double-word),weassociateeachdouble-wordoftheapplicationwithonebitinadelimiterbitarrayandanotherbitinavaluebitarray,asillustratedinFigure4.Thedelimiterbitissetto’1’ifitcorrespondstothedouble-wordofachunk,otherwiseitissetto’0’.Suchencodingimplicitlystoresthesizeofthechunk,whichcanbecomputedbymultiplyingeight(bytes/bit)withthedistance(innumberofbits)betweentwoconsecutivedelimiterbitswithvaluesof’1’.Thebitsinthevaluebitarrayhavetwouses.Therstandthelastbitsforachunkindicatewhetherthechunkisfree(’F’)orallocated(’A’).Othervaluebitsforthechunkareignored(’d’standsfor“don’tcare”)unlessthereareenoughofthemtostorethechunk’ssizedirectly.Figure4showsanexamplemeta-datainformationforchunkX.Therstdelimiterbitis’1’,indicatingthestartofchunkX,whilethevaluebitis’A’indicatesthatXisanallocatedchunk.AllotherdelimiterbitsforXarezero.Thestartofthenextchunk(ChunkY)isindicatedbyadelimiterbitvalueof’1’.ChunksthatarebeforeandafterXarefreeasindicatedbytheir’F’valuebits.Givenachunk’saddress,itsmeta-dataislocatedbysimplein-dexingtothedelimiterandvaluebitarrays,andthebitscorrespond-ingtothechunkareextractedthroughbitmasking.Tocomputethesizesofachunkanditsneighbors,delimiterbitsarefetchedas32-bitwords,andthelocationsof’1’sarefoundusingbitscanforward()andbitscanreverse()x86instructions.Forchunkswhosevaluebitsspanovermorethantwo32-bitwords,thechunk’ssizeisstoredandreaddirectlyfromthevaluebitarray.Tofacilitatefastre-allocationofdeallocatedchunks,wealsomaintainfree-liststructuressimilartotraditionalCheaplibraryimplementations[11].However,insteadofkeepingthe elds,weonlykeeptheaddressesoffreechunksandusethemtoaccessthebit-arrayswheretherestofthemeta-datacanbefound.Weadditionallyreducestorageoverheadofthefreelistsbyusingsingly-linkedlists,inwhicheachnodeonlystoresthechunk’saddressandthelist’sforwardpointer.Onanallocationordeallocationrequest,theheapmetadatabitmapfromtherequestedlocationisreadandcheckedforvalidity,e.g.thatadeallocationistoavalidchunkthatiscurrentlyallocated.Aninvalidfreeisdetectedasadeallocationtoanon-validchunk:theaddressisoutofrange,nobitsexistforthataddress,orthedelimiterandvaluebitsforthesupposedstartofthechunkarenot’1A’.Adoublefreeisdetectedasadeallocationtoafreechunk:thedelimiterandvaluebitsarealready’1F’,exceptifthechunkisalreadyconsolidatedinwhichcasetheHeapServerdetectsitasadeallocationtoanon-validchunk.Comparedtotraditionalinterleavedmeta-dataimplementation,HeapServerincursanextra3.125%overheadtokeepthedelim-iterandvaluebitarrays.Ourexperimentsfoundthattheperfor-manceoverheadduetoourbitmappedorganizationisnegligible. sizeinthesystem,halfofthemattheapplication’sside,andtheotherhalfattheHeapServer’sside.Pre-allocationmispredictionsarelargelyinconsequential.Un-usedpre-allocatedchunksmayresultinmemoryfragmentation,butlargefragmentationisavoidedbyonlyusingpre-allocationforsmallchunksizes(lessthan512Bytes).Overall,pre-allocationop-timizationhidesthecommunicationandallocationoverheadformostfrequentallocationsand,togetherwithnon-blockingandbulkdeallocationoptimizations,allowstheHeapServerandapplicationexecutiontoproceedalmostfullyinparallel.4.2.2CommunicationProtocolCommunicationbetweentheapplicationanditsHeapServerpro-cessusesstandardSystemVmessage-passing.Theapplicationsetsuptwomessagequeues:aRequestQueueforsendingheaprequeststotheHeapServer,andaReplyQueueforreceivingHeapServer’sreplies.Amessage hasthreeesthetypeofthemessage, isapointertoamemorylocation,andintegercontainsadditionalinformationforsomerequests.Table2liststherequestandreplymessagetypesandtheirasso- contents.Whentheapplicationprocessperformsitsrstheapallocation,itusesansystemcallwithazeroargumenttorequestthestartingaddressofitsheapmemoryspacefromtheoperatingsystem,whichreturnsapointertothebaseaddressoftheheapmemory.Thentheapplicationcreatesthemes-sagequeuesandforksaHeapServerprocess.TheHeapServertheninitializesitsmeta-datastructuresusingtheapplication’sheapbaseaddress,andconnectstotherequestandreplymessagequeues.Duetospacelimitation,wewillonlydescribecommunicationprotocolforrequest.Foralibrarycall,arequestissenttoHeapServer.TheServerreplieswithamessagethatcontainstheaddressofthenewlyallocatedchunk.IfHeapServercannotsatisfyanallocationrequestbecausetheapplication’scurrentheapregionistoosmall,itrequestsadditionalheapmemorybysendingapositivevalueinthe ofthereply.Theapplicationthenextendsitsheapregionbytherequestedsizethroughancall.WenotethatHeapServercannotdirectlyuseonbehalfoftheapplicationbecauseitrunsinaseparateaddressspace.The valuemayalsobeanegativevalueindicatingthattheapplicationmusttrimitsheapregionthroughancall.Thisensuresthattheapplication’smemoryfootprintiskepttoaminimum.Whentheapplicationprocesscompletesexecution,itcansendmessagetotheHeapServer,whichdeallocatestheprocess’heapmeta-dataandterminatesexecution.4.2.3SecurityConsiderationsOnepotentialvulnerabilityofthestandardmessagingsysteminSystemVimplementationisthatthemessagequeuesareglobalandanyprocessthatbelongstothesameuserID(UID)canlistentothem.Althoughitisunlikelythatremoteattackershaveanaccesstosuchaprocess,acombinationofattackers’effortandthelocalusers’carelessnessinhandlingthemessagequeueIDscanbreaktheheapserverprotection.Toavoidthat,wecouldaddprocessidauthenticationtothemessagingsystem.Amessagequeuecontainsthelistofprocessidsthatcanreadfromorwritetothequeue,andonlytheownerofthequeue(theapplication)canmodifythelist.Furthermore,thequeuecanonlybeclosedbytheowner,orbytheOSifitdetectsthatthequeuehasbeenorphaned,i.e.theownerprocesshasdiedbutthequeueandHeapServerarestillaround.AsecondconcernspecictoHeapServerisrelatedtothebulkdeallocationandpre-allocationoptimizations,wheretheapplica-tionmaintainsbulkdeallocationrequestsandpre-allocatedpointerlistinitsaddressspace.Thesestructurescanbeconsideredasanewtypeofmeta-datathatmaybetargetedbyattacks.Consequently,weprotectthemrigorously.First,becausetheamountofnewmeta-dataissmallandboundedinsize,wecanduplicateitbywritingidenticalcopiesatdifferentrandomlocations.Beforemeta-dataisused,allcopiesarefetched,compared,andanattackisdetectedifnotallcopiesareidentical.Notethatkeepingseparateidenticalcopiesofmeta-datacannotbeeasilyorcheaplydoneiftheappli-cationmaintainsofitsheapmeta-datainitsaddressspacebe-causeofthesheeramountofmeta-datainvolved.OurcurrentHeapServerimplementationincludestwoseparatecopiesofbulkdeallo-cationrequestsandpre-allocatedpointersattheapplication’sside.Secondly,wedelimitbothmeta-datacopieswithwrite-protectedpagessothatacontiguousmeta-dataoverwriteattemptwillbein-stantlydetected.Finally,themeta-datainthepre-allocationarrayisnottheonlycopyinthesystem,sinceHeapServermaintainsaredundantmeta-datainformation.Thus,HeapServerhassomeabilitytodetectanomalies.Forexample,whenanaddressofapre-allocatedchunkiscorrupted,thesubsequentdeallocationrequestofthechunkwillfailtocorrespondtothevalidchunkinformationandbedetectedbytheHeapServer.4.3HeapLayoutObfuscationWhileheapmeta-dataisseparatelyprotectedandonlyaccessiblebyHeapServer,heapdataneedstobeprotectedaswell.Toprotectheapdata,HeapServerusesaddressobfuscation[5],whichinsertsrandompaddingbetweenheapchunkstopreventattackersfromknowingexactlocationsofcriticalheapdata.Thepaddingsizeisbetweenzerobytes(nopadding)andtheminimumof%oftherequestedchunksize(weuse=64).Thechoiceofisatradeoffbetweenprotectionandfragmentation.WeskippaddingforverysmallchunkstoavoidInorderfordifferentprograminstancestohavedifferentran-domization,therandomseedtousecanbedeterminedatrun-timebyhashingtogetherthehigh-resolutionreal-timeclock,applicationcharacteristics,andsystemstatesuchasthenumberofcurrently-waitingprocesses,totalavailablememory,etc.Thisrandomizationdoesnotnecessarilyrestrictdebuggabilityoftheprogramsincetheheapmeta-datastatemaintainedbytheHeapServercanitselfbeusedasvaluabledebugginginformation.However,addressobfuscationalonestillleavesthesystemtoovulnerable.First,althoughpaddingbetweenchunksisrandom,al-locationanddeallocationsequencesarenotrandom.Thismeansthatdifferentinstancesofaprogram,giventhesameinput,willhavethesamesequentiallayoutofchunksinmemory,albeitwithdifferentamountofpaddingsbetweenchunks.Forexample,ifinoneinstanceofaprogramchunkAandBareconsecutive,theninanotherinstancetheywillalsobeconsecutive.Werefertothislayoutpredictability.Layoutpredictabilityallowsabrute-forceguessingofpaddingamount,inwhichanattackthatworksononeinstanceofaprogramcanalsoworkonanotheraslongasthepaddingamountiscorrectlyguessed.WealreadynoteinSection2thatpadding-basedobfuscationtechniqueshavelowentropy,soasmallnumberofguessesareneededtosuccessfullybreakit.An-otherfactorcontributingtolayoutpredictabilityisthewaycurrentchunkrecyclingalgorithmswork.Tooptimizefortemporallocal-ity,inmanylibrariesadeallocatedchunkisoftenimmediatelyre-cycled(re-allocated)whenthereisanallocationrequesttothesamesize.Suchtemporallocalityoptimizationcreatesapredictablepat-ternthatallowsattackerstoguesswhichchunksarelikelytobeconsecutiveintheheap,andthenusethepreviouschunktoover-owintothefunctionpointerinthenextchunk.Inordertoremovelayoutpredictabilityandpredictabilityintherecyclingpattern,ourproposedlayoutobfuscationchunkrecyclingpatternsbyselectingarandomchunktoreallocatefromthefreelist.Toimplementtherandomrecycling,wewaituntilafreelisthasatleastfourchunksbeforeallowingachunkfromthelisttoberecycledforallocation(thisrequirementisrelaxedfor theimpactontheapplicationvarieswiththeoverowamount.Iftheoverowisentirelywithinthechunk’spadding,theattackhasnoeffectontheapplication.Iftheoverowoverwritesheapdatainthenextchunk,theapplicationeithercrashesorproduceswrongcomputationresults.Functionpointeroverwriteattempts,however,sometimessuc-ceedinhijackingthecontrolowwhentheactualpaddingamountiscorrectlyguessed.Whentheoverowislargerthanthepaddingamount,theoverowalsocorruptsdatainthenextchunk.Sinceourattackkernelsareappliedagainstaveryregularapplicationwhichonlyhasheapobjectsofthesamesizeandeachobjecthasbothafunctionpointerandavulnerablebuffer,anyoverowintothenextchunkresultsinasuccessfulcontrolowhijack.Realapplicationshavefewervulnerablebuffersandfunctionpointersintheheapandaremuchlesspronetodataoverwriteattacks.6.2BenchmarkCharacteristics Average Heap Requests per Second0010010,000100,0001,000,00010,000,000cfracrichards Figure6.Averageheaprequestspersecond(logarithmicscale)Heaprequestfrequency.Figure6showstheheaprequestfre-quency,measuredasthetotalnumberofallocationanddeallocationrequestspersecond,foreachapplication.SPEC2000benchmarksareshownontheleft,whiletheallocation-intensivebenchmarksareshownontherightofthegure.Thegureshowsthatthebenchmarkshaveawiderangeofheaprequestsfrequency:high–morethan2,000upto3,367,281(deltaBlue,equake,espresso,lindsay,perlbmk,richards,roboop,andvortex),medium/low–therestofthebenchmarks.Wepayparticularattentiontobenchmarkswithhighheaprequestfrequencies,becausetheystresstheperfor-manceofourheapprotectionmechanismsthemost.Mostoftheallocation-intensivebenchmarksexceptcfracandLRUsimareinthiscategory.Notethatroboop,aC++object-orientedroboticma-nipulatorsimulation,hasatleastoneorderofmagnitudehigherheaprequestfrequencycomparedtoallotherbenchmarks.Onav-erage,itmakesoneheaprequestevery594processorcycles,anddoesverylittlecomputationbeyondmakingheaprequests.Hence,robooprepresentsagoodworst-casescenariototestourschemes.Heaprequesttypesandsizes.Duetothespacelimitations,weonlyprovideasummaryofourdataonheaprequesttypeandsize.Wefoundthatinallbenchmarkswithhighheaprequestfrequen-cies,deallocationrequestsaccountforroughlyhalfofallheapre-quests.Thismakessensebecauseallocationsarefrequent,andheapmemorywouldgrowquicklywithoutfrequentdeallocations.Asaresult,thesebenchmarksareexpectedtobenetfromourdealloca-tionoptimizations(bulkdeallocationsandnon-blockingcommu-nication)aswellasfromallocationoptimizations(pre-allocationsandnon-blockingcommunication).Wealsofoundthatallbench-markswithhighheaprequestfrequencieshaveasmallaverageheaprequestsize,rangingfrom2bytesforlindseyto235bytesfordeltaBlue.Thismakessensebecauselargeobjectswouldtakemoretimetoinitializeanduse,preventingtheapplicationfrommakingheaprequestsasfrequently.Theinverse,however,isnottrue:someapplicationswithlowheaprequestfrequenciesalsohavesmallrequestsizes.Bothheaprequesttypesandsizesforbenchmarkswithhighheaprequestratessupportourchoiceofbit-mappedheapmeta-dataorganizationbecausetheyareefcientinstoragewhentheaverageheapchunksizeissmall,andallowfastlookupsforthesedemandingbenchmarks.6.3HeapServer’sPerformanceExecutiontimeoverheads.Figure7showstheexecutiontimeoverheadsofHeapServerwhensomeorallofitscomponentsareimplemented,comparedtotheexecutiontimeofthebase(nopro-tections)library.Thebarsshowtheoverheadswhenthebitmappedheapmeta-dataorganizationisused,butisstoredintheapplication’saddressspaceandnoobfuscationisused.Thebarsshowwhenlayoutobfuscationisadded.Fi-nally,thebarsshowafullHeapServerimplementationthatincludesthebitmappedheapmeta-dataorganization,layoutobfus-cations,keepingmeta-dataintheHeapServerprocess,andusingallHeapServercommunicationoptimizations.Thegureshowsthatourbit-mappedmeta-dataorganization(Section4.1)hasnearlynegligibleperformanceoverheadsof-0.5%and2.5%onaverageforSPEC2000andallocation-intensivebenchmarks,respectively.Insomecases,itevenspeedsupexecution(9%inequakeand4%intwolf),becausethemorecompactheapdatalayoutproducesbet-terspatiallocality.Inothercases,itslowsdowntheexecution:6%inammp,deltaBlue,andespresso,9%inroboop,and2%inlind-sayandeon.Thisisduetotheextrameta-datalookuptimeandduetothestorageoverheadtostorethemeta-data.Thebarsindicatethatourlayoutobfuscationleavesaverageperfor-mancelargelyunchanged.However,thefragmentationintheheapdataspaceduetorandompaddingandlongertraversalforheapobjectrecyclingpenalizeroboopby29%.Thebarsshowthatafully-optimizedfullimplementationofHeapServer,onaver-age,produces-0.4%overheadforSPEC2000benchmarksand2%overheadsfortheallocation-intensivebenchmarks.Thefullimple-mentationevenspeedsupsevenbenchmarks(bzip2,crafty,equake,gap,twolf,deltaBlue,andLRUsim),andinthreebenchmarksthespeedupsaresignicant:14%indeltaBlue,10%inequake,and7%intwolf.implementseverythinginandalsosuffersfromthehighinter-processcommunicationlatencies.Ifitwereunoptimized,itsexecutiontimeoverheadswouldbestrictlyhigher.ThefactthatperformsbetterthaninmostcasessigniesthattheparallelismbetweentheapplicationandtheoptimizedHeapServermorethanoffsetstheinter-processcommunicationlatencies.ExecutiontimeoverheadsofanalternativetoHeapServerOnemayimagineanalternativetotheHeapServerinwhichweusebitmappedheapmeta-datatoseparatethestorageofheapmeta-datafromheapdata,layoutobfuscationtoprotectheapdata,butaddpage-levelwrite-protectiontotheheapmeta-data.Theheapman-agementlibraryunprotectsthepagesthatholdtheheapmeta-datawhenitneedstomodifythem,butimmediatelywrite-protectsthepagesbeforereturningtotheusercode.Toimplementthis,wesim-plywraptheheapmanagementlibraryfunctionswithsystemcallstounprotectandprotecttheheapmeta-datapages.Fig-ure8showstheresultingperformanceoverheads,whicharehugeforbenchmarkswithhighheaprequestfrequency:theslowdownismorethan20XindeltaBlue,espresso,perlbmk,androboop.Wein-vestigatedthisfurtherbycountingthenumberofandfoundoutthatonaverage,onesuchsystemcallintroducesthousandsofcyclesofoverheadduetoanexception,pipelinecontextswitchlatency,TLBush,andsomecacheushes.Evenifthesystemcallsarehighlyoptimized(e.g.throughfastsystemcalls),itisunlikelythattheseoverheadscanbereducedtothelevelofourHeapServerimplementation. arestillinterestedinndingjusthowmuchHeapServerutilizesaprocessor.Figure10showsabreakdownoftimetheHeapServerprocessspendsonservicingheaprequestsfromtheapplication.indicatesthattheHeapServerisidle,nothavingaheaprequesttoservice.ThegureshowsthattheHeapServerisbusylessthan6%ofthetimeforallbutonebenchmark.Evenforro-boop,theHeapServerisbusyonly24%ofthetime.Hence,theextraprocessorutilizationofHeapServerisactuallyverysmall.Weleavehowthisobservationcanbeexploitedforfuturestudy. Heap Server's Occupancy0%5%15%20% Figure10.HeapServersoccupancy.7.ConclusionsWehaveproposedandevaluatedanewschemeforcomprehen-sivelyprotectingtheheapmeta-dataaswellasheapdatafromsecurityattacks.Initsfullimplementation,ourschemeprotectsagainstcontiguousandnon-contiguousoverwritesonheapmeta-data,andmakesoverwritesofheapdatamoredifcult.Weshowthatourapproachusesminimalassumptionsonthemechanismsofthelatterstagesofanattack,utilizesexistinghardwarepro-tectionmechanisms,andrequiresmodicationsonlytotheallo-cation/deallocationroutines.Wedemonstratethatanalternativeheapmeta-dataprotectionthroughexistingkernel-levelpageprotectionproducesunaccept-ableperformanceoverheads.Incontrast,ourschemesachievesnearly-negligibleperformanceoverheadsforapplicationswithawide-rangeofheapbehavior.Weachievesuchlowperformanceoverheadsusingaggressiveoptimizationsandbyexploitingparal-lelismbetweentheapplicationanditsHeapServer.Sincemanytechniqueshavebeenproposedforstackprotectionbutfewforheapprotection,webelievethattheheapprotectionofferedbyourschemeisasignicantcontributiontowardstheoverallsecurityofanapplication.References[1]AlexanderAnisimov,PositiveTechnologies.DefeatingMi-crosoftWindowsXPSP2HeapprotectionandDEPbypass.http://www.maxpatrol.com/defeating-xpsp2-heap-protection.htm[2]Anonymous.Onceuponafree().PhrackMagazine,57(9),2001.[3]E.BergerandB.Zorn.Diehard:Probabilisticmemorysafetyforunsafelanguages.InACMSIGPLANConf.onProgrammingLanguageDesignandImplementation,2006.[4]E.D.Berger,K.S.McKinley,R.D.Blumofe,andP.R.Wilson.Hoard:AScalableMemoryAllocatorforMultithreadedApplications.Proc.ofthe9thIntl.Conf.onArchitecturalSupportforProgrammingLanguagesandOperatingSystems(ASPLOS-IX),pages117–128,[5]S.Bhatkar,D.C.DuVarney,andR.Sekar.AddressObfuscation:anEfcientApproachtoCombataBroadRangeofMemoryErrorinProc.ofthe12thUSENIXSecuritySymp.,pages105–120,[6]S.Chen,J.Xu,E.C.Sezer,P.Gauriar,andR.K.Iyer.Non-Control-DataAttacksAreRealisticThreats.inProc.ofthe14thUSENIXSecuritySymp.,pages177–192,2005.[7]C.Cowan,S.Beattie,J.Johansen,andP.Wagle.PointGuard:ProtectingPointersfromBufferOverowVulnerabilities.inProc.ofthe12thUSENIXSecuritySymp.,pages91–104,2003.[8]C.Cowan,C.Pu,D.Maier,J.Walpole,P.Bakke,S.Beattie,A.Grier,P.Wagle,Q.Zhang,andH.Hinton.StackGuard:AutomaticAdaptiveDetectionandPreventionofBuffer-OverowAttacks.inProc.ofthe7thUSENIXSecuritySymp.,pages63–78,1998.[9]Darkeagle.MozzilaGIFImageProcessingLibraryRemoteHeapOverowVulnerability.http://www.securityfocus.com/bid/12881/exploit[10]D.L.Detlefs,A.Dosser,andB.Zorn.MemoryAllocationCostsinLargeCandC++Programs.SoftwarePracticeandExperience,pages527–542,1994.[11]DougLea.AMemoryAllocator.http://gee.cs.oswego.edu/dl/html/,2000.[12]G.Suh,J.Lee,andS.Devadas.Secureprogramexecutionviadynamicinformationowtracking.InProc.ofthe11thIntl.Conf.onArchitecturalSupportforProgrammingLanguagesandOperatingSystems.Boston,MA,2004.[13]H.Shacham,M.Page,B.Pfaff,E.-J.Goh,N.Modadugu,andD.Boneh.Ontheeffectivenessofaddressspacerandomization.InProc.oftheACMConf.onComputerandCommunicationsSecurity,2004.[14]J.R.CrandallandF.T.Chong.Minos:Controldataattackpreventionorthogonaltomemorymodel.ToappearinProc.ofthe37thIntl.Symp.onMicroarchitecture.Portland,OR,2004.[15]Jones,Richard,andRafaelLins.GarbageCollection:AlgorithmsforAutomaticDynamicMemoryManagement.JohnWiley&Sons,NewYork,1996.[16]V.Kiriansky,D.Bruening,andS.Amarasinghe.SecureExecutionviaProgramShepherding.In11thUSENIXSecuritySymp.,2002.[17]LinuxProgrammer’sManual.ManPagesMSGOP(2).2002.[18]MattConoverandw00w00SecurityTeam.w00w00onHeapOverows.http://www.w00w00.org/,1999.[19]NathanTuck,BradCalderandGeorgeVarghese.HardwareandBinaryModicationSupportforCodePointerProtectionFromBufferOverow.Proc.ofthe37thannualIEEE/ACMIntl.Symp.onMicroarchitecture,pages209–220,2004.[20]PaXTeam.PaXAddressSpaceLayoutRandomization(ASLR).http://pax.grsecurity.net/docs/aslr.txt,2003.[21]F.PerriotandP.Szor.AnAnalysisoftheSlapperWormEx-http://securityresponse.symantec.com/avcenter/reference/anal-ysis.slapper.worm.pdf,2003.[22]R.Wojtczuk.DefeatingSolarDesignerNon-executableStackPatch.http://seclists.org/lists/bugtraq,experimentalstudyofsecurityvulnerabilitiescausedbyerrors.InProc.oftheIEEEIntl.Conf,1998.[23]S.AndersenandV.Abella.DataExecutionPrevention.ChangestoFunctionalityinMicrosoftWindowsXPServicePack2,Part3:Mem-oryProtectionTechnologies.http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2mempr.mspx,2004.[24]SecurityFocus.Wu-FtpdFileGlobbingHeapCorruptionVulnerabil-ity.http://www.securityfocus.com/bid/3581,2002.[25]SecurityFocus.SudoPasswordPromptHeapOverowVulnerability.http://www.securityfocus.com/bid/4593,2003.[26]SecurityFocus.MicrosoftWindowswinhlp32.exeHeapOverVulnerability.http://www.securityfocus.com/archive/1/385332/2004-,2004.[27]StandardPerformanceEvaluationCorporation.SPECCPU2000http://www.spec.org/osg/cpu2000/,2000.[28]US-CERT.CVSHeapOverowVulnerability.www.uscert.gov/cas/techalerts/index.html,pagesTA04–147A,2004.[29]US-CERT.HTTPParsingVulnerabilitiesinCheckPointFirewall-1.www.uscert.gov/cas/techalerts/index.html,pagesTA04–036A,2004.[30]US-CERT.MicrosoftInternetExplorervulnerabletobufferoverviaFRAMEandIFRAMEelements.http://www.kb.cert.org/vuls/id/842160pageVU842160,2004.[31]J.Xu,Z.Kalbarczyk,andR.K.Iyer.TransparentRuntimeRandomizationforSecurity.inProc.ofthe22ndIntl.Symp.onReliableDistributedSystems,pages260–269,2003.