/
overhead[35].Weobservethat,inordertorendercontrol-owhijacksimpossible overhead[35].Weobservethat,inordertorendercontrol-owhijacksimpossible

overhead[35].Weobservethat,inordertorendercontrol-owhijacksimpossible - PDF document

pamella-moone
pamella-moone . @pamella-moone
Follow
387 views
Uploaded On 2016-07-10

overhead[35].Weobservethat,inordertorendercontrol-owhijacksimpossible - PPT Presentation

onmetadatax322andaninstructionlevelisolationmechanismthatpreventsnonprotectedmemoryoperationsfromaccessingthesaferegionx323Forperformancereasonswehandlereturnaddressesstoredonthestackse ID: 399158

onmetadata(x3.2.2) andaninstruction-levelisolationmechanismthatpreventsnon-protectedmemoryopera-tionsfromaccessingthesaferegion(x3.2.3).Forperfor-mancereasons wehandlereturnaddressesstoredonthestackse

Share:

Link:

Embed:

Download Presentation from below link

Download Pdf The PPT/PDF document "overhead[35].Weobservethat,inordertorend..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.


Presentation Transcript

overhead[35].Weobservethat,inordertorendercontrol-owhijacksimpossible,itissufcienttoguaran-teetheintegrityofcodepointers,i.e.,thosethatareusedtodeterminethetargetsofindirectcontrol-owtransfers(indirectcalls,indirectjumps,orreturns).Thispaperintroducescode-pointerintegrity(CPI),awaytoenforceprecise,deterministicmemorysafetyforallcodepointersinaprogram.Thekeyideaistosplitprocessmemoryintoasaferegionandaregularregion.CPIusesstaticanalysistoidentifythesetofmemoryob-jectsthatmustbeprotectedinordertoguaranteememorysafetyforcodepointers.Thissetincludesallmemoryobjectsthatcontaincodepointersandalldatapointersusedtoaccesscodepointersindirectly.Allobjectsinthesetarethenstoredinthesaferegion,andtheregionisisolatedfromtherestoftheaddressspace(e.g.,viahard-wareprotection).Thesaferegioncanonlybeaccessedviamemoryoperationsthatareprovenatcompiletimetobesafeorthataresafety-checkedatruntime.Thereg-ularregionisjustlikenormalprocessmemory:itcanbeaccessedwithoutruntimechecksand,thus,withnoover-head.Intypicalprograms,theaccessestothesaferegionrepresentonlyasmallfractionofallmemoryaccesses(6.5%ofallpointeroperationsinSPECCPU2006needprotection).Existingmemorysafetytechniquescannotefcientlyprotectonlyasubsetofmemoryobjectsinaprogram,rathertheyrequireinstrumentingallpotentiallydangerouspointeroperations.CPIfullyprotectstheprogramagainstallcontrol-owhijackattacksthatexploitprogrammemorybugs.CPIrequiresnochangestohowprogrammerswritecode,sinceitautomaticallyinstrumentspointeraccessesatcompiletime.CPIachieveslowoverheadbyselectivelyinstrumentingonlythosepointeraccessesthatareneces-saryandsufcienttoformallyguaranteetheintegrityofallcodepointers.TheCPIapproachcanalsobeusedfordata,e.g.,toselectivelyprotectsensitiveinformationliketheprocessUIDsinakernel.Wealsointroducecode-pointerseparation(CPS),are-laxedvariantofCPIthatisbettersuitedforcodewithabundantvirtualfunctionpointers.InCPS,allcodepointersareplacedinthesaferegion,butpointersusedtoaccesscodepointersindirectlyareleftintheregularre-gion(suchaspointerstoC++objectsthatcontainvirtualfunctions).UnlikeCPI,CPSmayallowcertaincontrol-owhijackattacks,butitstilloffersstrongerguaranteesthanCFIandincursnegligibleoverhead.Ourexperimentalevaluationshowsthatourproposedapproachimposessufcientlylowoverheadtobede-ployableinproduction.Forexample,CPSincursanaverageoverheadof1.2%ontheCprogramsinSPECCPU2006and1.9%forallC/C++programs.CPIincursonaverage2.9%overheadfortheCprogramsand8.4%acrossallC/C++SPECCPU2006programs.CPIandCPSareeffective:theyprevent100%oftheattacksintheRIPEbenchmarkandtherecentattacks[19,15,9]thatbypassCFI,ASLR,DEP,andallotherMicrosoftWin-dowsprotections.WecompileandrunwithCPI/CPSacompleteFreeBSDdistributionalongwith100widelyusedpackages,demonstratingthattheapproachisprac-tical.Thispapermakesthefollowingcontributions:1.Denitionoftwonewprogrampropertiesthatof-ferasecurity-benettoenforcement-costratiosu-periortothestateoftheart:code-pointerin-tegrity(CPI)guaranteescontrolowcannotbehi-jackedviamemorybugs,andcode-pointersepa-ration(CPS)providesstrongersecurityguaranteesthancontrol-owintegritybutatnegligiblecost.2.Anefcientcompiler-basedimplementationofCPIandCPSforunmodiedC/C++code.3.TherstpracticalandcompleteOSdistribution(basedonFreeBSD)withfullprotectionbuilt-inagainstcontrol-owhijackattacks.Intherestofthepaperweintroduceourthreatmodel(x2),describeCPIandCPS(x3),presentourim-plementation(x4),evaluateourapproach(x5),discussrelatedwork(x6),andconclude(x7).WeformalizetheCPIenforcementmechanismandprovideasketchofitscorrectnessproofinAppendixA.2ThreatModelThispaperisconcernedsolelywithcontrol-owhijackattacks,namelyonesthatgivetheattackercontroloftheinstructionpointer.Thepurposeofthistypeofattackistodivertcontrolowtoalocationthatwouldnototh-erwisebereachableinthatsamecontext,hadthepro-gramnotbeencompromised.Examplesofsuchattacksincludeforcingaprogramtojump(i)toalocationwheretheattackerinjectedshellcode,(ii)tothestartofachainofreturn-orientedprogramfragments(“gadgets”),or(iii)toafunctionthatperformsanundesirableactioninthegivencontext,suchascallingsystem()withattacker-suppliedarguments.Data-onlyattacks,i.e.,thatmodifyorleakunprotectednon-controldata,areoutofscope.Weassumepowerfulyetrealisticattackercapabilities:fullcontroloverprocessmemory,butnoabilitytomod-ifythecodesegment.Attackerscancarryoutarbitrarymemoryreadsandwritesbyexploitinginput-controlledmemorycorruptionerrorsintheprogram.Theycan-notmodifythecodesegment,becausethecorrespondingpagesaremarkedread-executableandnotwritable,andtheycannotcontroltheprogramloadingprocess.Theseassumptionsensuretheintegrityoftheoriginalprogramcodeinstrumentedatcompiletime,andenablethepro-gramloadertosafelysetuptheisolationbetweenthesafeandregularmemoryregions.Ourassumptionsareconsistentwithpriorworkinthisarea.2 onmetadata(x3.2.2),andaninstruction-levelisolationmechanismthatpreventsnon-protectedmemoryopera-tionsfromaccessingthesaferegion(x3.2.3).Forperfor-mancereasons,wehandlereturnaddressesstoredonthestackseparatelyfromtherestofthecodepointersusingasafestackmechanism(x3.2.4).3.2.1CPIStaticAnalysisWedeterminethesetofsensitivepointersusingtype-basedstaticanalysis:apointerissensitiveifitstypeissensitive.Sensitivetypesare:pointerstofunctions,pointerstosensitivetypes,pointerstocompositetypes(suchasstructorarray)thatcontainsoneormoremem-bersofsensitivetypes,oruniversalpointers(i.e.,void*,char*andopaquepointerstoforward-declaredstructsorclasses).Aprogrammercouldadditionallyindicate,ifdesired,othertypestobeconsideredsensitive,suchasstructucredusedintheFreeBSDkerneltostorepro-cessUIDsandjailinformation.Allcodepointersthatacompilerorruntimecreatesimplicitly(suchasreturnad-dresses,C++virtualtablepointers,andsetjmpbuffers)aresensitiveaswell.Oncethesetofsensitivepointersisdetermined,weusestaticanalysistondallprograminstructionsthatmanipulatethesepointers.Theseinstructionsincludepointerdereferences,pointerarithmetic,andmemory(de-)allocationoperationsthatcallstoeither(i)corre-spondingstandardlibraryfunctions,(ii)C++new/deleteoperators,or(iii)manuallyannotatedcustomallocators.Thederivedsetofsensitivepointersisover-approximate:itmayincludeuniversalpointersthatneverenduppointingtosensitivevaluesatruntime.Forin-stance,theC/C++standardallowschar*pointerstopointtoobjectsofanytype,butsuchpointersarealsousedforCstrings.Asaheuristic,weassumethatchar*pointersthatarepassedtothestandardlibcstringmanipulationfunctionsorthatareassignedtopointtostringconstantsarenotuniversal.Neithertheover-approximationnorthechar*heuristicaffectthesecurityguaranteesprovidedbyCPI:over-approximationmerelyintroducesextraover-head,whileheuristicerrorsmayresultinfalseviolationreports(thoughweneverobservedanyinpractice).Memorymanipulationfunctionsfromlibc,suchasmemsetormemcpy,couldintroducealotofoverheadinCPI:theytakevoid*arguments,soalibccompiledwithCPIwouldinstrumentallaccessesinsidethefunctions,regardlessofwhethertheyareoperatingonsensitivedataornot.CPI'sstaticanalysisinsteaddetectssuchcasesbyanalyzingtherealtypesoftheargumentspriortobeingcasttovoid*,andthesubsequentinstrumentationpasshandlesthemseparatelyusingtype-specicversionsofthecorrespondingmemorymanipulationfunctions.Weaugmentedtype-basedstaticanalysiswithadata-owanalysisthathandlesmostpracticalcasesofunsafepointercastsandcastsbetweenpointersandintegers.Ifavaluevisevercasttoasensitivepointertypewithinthefunctionbeinganalyzed,orispassedasanargumentorreturnedtoanotherfunctionwhereitiscasttoasen-sitivepointer,theanalysisconsidersvtobesensitiveaswell.Thisanalysismayfailwhenthedataowbetweenvanditscasttoasensitivepointertypecannotbefullyre-coveredstatically,whichmightcausefalseviolationre-ports(wehavenotobservedanyduringourevaluation).Suchcastsareacommonproblemforallpointer-basedmemorysafetymechanismsforC/C++thatdonotre-quiresourcecodemodications[34].AkeybenetofCPIisitsselectivity:thenumberofpointeroperationsdeemedtobesensitiveisasmallfrac-tionofallpointeroperationsinaprogram.Asweshowinx5,forSPECCPU2006,theCPItype-basedanaly-sisidentiesforinstrumentation6:5%ofallpointerac-cesses;thistranslatesintoareductionofperformanceoverheadof16–44relativetofullmemorysafety.Nevertheless,westillthinkCPIcanbenetfrommoresophisticatedanalyses.CPIcanleverageanykindofpoints-tostaticanalysis,aslongasitprovidesanover-approximatesetofsensitivepointers.Forinstance,whenextendingCPItoalsoprotectselectnon-code-pointerdata,wethinkDSA[27,28]couldprovemoreeffective.3.2.2CPIInstrumentationCPIinstrumentsaprograminorderto(i)ensurethatallsensitivepointersarestoredinasaferegion,(ii)createandpropagatemetadataforsuchpointersatruntime,and(iii)checkthemetadataondereferencesofsuchpointers.Intermsofmemorylayout,CPIintroducesasafere-gioninadditiontotheregularmemoryregion(Fig.2).Storagespaceforsensitivepointersisallocatedinboththesaferegion(thesafepointerstore)andtheregularregion(asusual);oneofthetwocopiesalwaysremainsunused.Thisisnecessaryforuniversalpointers(e.g.,void*),whichcouldbestoredineitherregiondepend-ingonwhethertheyaresensitiveatruntimeornot,andalsohelpstoavoidsomecompatibilityissuesthatarisefromthechangeinmemorylayout.Theaddressinregu-larmemoryisusedasanoffsettotolookupthevalueofasensitivepointerinthesafepointerstore.Thesafepointerstoremapstheaddress&pofsensi-tivepointerp,asallocatedintheregularregion,tothevalueofpandassociatedmetadata.Themetadataforpdescribesthetargetobjectonwhichpisbased:lowerandupperaddressboundsoftheobject,andatemporalid(seeFig.2).ThelayoutofthesafepointerstoreissimilartometadatastorageinSoftBounds+CETS[35],exceptthatCPIalsostoresthevalueofpinthesafepointerstore.Combinedwiththeisolationofthesafere-gion(x3.2.3),thisallowsCPItoguaranteefullmemorysafetyofallsensitivepointerswithouthavingtoinstru-4 afewrareexceptions,likeunloadingasharedlibrary,whicharehandledseparately).Thisreducesthesizeofthesaferegionandthenumberofmemoryaccesseswhenloadingorstoringcodepointers.Ifthesaferegionisorganizedasasimplearray,aCPS-instrumentedpro-gramperformsessentiallythesamenumberofmemoryaccesseswhenloadingorstoringcodepointersasanon-instrumentedone;theonlydifferenceisthatthepointersarebeingloadedorstoredfromthesafepointerstorein-steadoftheiroriginallocation(universalpointerloadorstoreinstructionsstillintroduceoneextramemoryaccesspersuchinstruction).Asaresult,CPScanbeenforcedwithlowperformanceoverhead.CPSguaranteesthat(i)codepointerscanonlybestoredtoormodiedinmemorybycodepointerstoreinstructions,and(ii)codepointerscanonlybeloadedbycodepointerloadinstructionsfrommemorylocationstowhichpreviouslyacodepointerstoreinstructionstoredavalue.Combinedwiththesafestack,CPSpreciselyprotectsreturnaddresses.CPSisstrongerthanmostCFIimplementations[1,54,53],whichallowanyvulnerableinstructioninaprogramtomodifyanycodepointer;theyonlycheckthatthevalueofacodepointer(whenusedinanindirectcontroltransfer)pointstoafunctiondenedinaprogram(forfunctionpointers)ordirectlyfollowsacallinstruction(forreturnaddresses).CPSguarantee(i)aboverestrictstheattacksurface,whileguarantee(ii)restrictstheattacker'sexibilitybylimitingthesetoflo-cationstowhichthecontrolcanberedirected—thesetincludesonlyentrypointsoffunctionswhoseaddresseswereexplicitlytakenbytheprogram.Toillustratethisdifference,considerthecaseofthePerlinterpreter,whichimplementsitsopcodedispatchbyrepresentinginternallyaPerlprogramasasequenceoffunctionpointerstoopcodehandlersandthencallinginitsmainexecutionloopthesefunctionpointersonebyone.CFIstaticallyapproximatesthesetoflegitimatecontrol-owtargets,whichinthiscasewouldincludeallpossiblePerlopcodes.CPShoweverpermitsonlycallsthroughfunctionpointersthatareactuallyassigned.ThismeansthatamemorybuginaCFI-protectedPerlin-terpretermaypermitanattackertodivertcontrolowandexecuteanyPerlopcode,whereasinaCPS-protectedPerlinterpretertheattackercouldatmostexecuteanop-codethatexistsintherunningPerlprogram.CPSprovidesstrongcontrol-owintegrityguaranteesandincurslowoverhead(x5).WefoundthatitpreventsallrecentattacksdesignedtobypassCFI[19,15,9].WeconsiderCPStobeasolidalternativetoCPIinthosecaseswhenCPI's(alreadylow)overheadseemstoohigh.4ImplementationWeimplementedaCPI/CPSenforcementtoolforC/C++,calledLevee,ontopoftheLLVM3.3com-pilerinfrastructure[30],withmodicationstoLLVMli-braries,theclangcompiler,andthecompiler-rtruntime.TouseLevee,onejustneedstopassadditionalagstothecompilertoenableCPI(-fcpi),CPS(-fcps),orsafe-stackprotection(-fstack-protector-safe).LeveeworksonunmodiedprogramsandsupportsLinux,FreeBSD,andMacOSXinboth32-bitand64-bitmodes.Leveecanbedownloadedfromtheprojecthome-pagehttp://levee.epfl.ch,andweplantopushourchangestotheupstreamLLVM.Analysisandinstrumentationpasses:Weimple-mentedthestaticanalysisandinstrumentationforCPIastwoLLVMpasses,directlyfollowingthedesignfromx3.2.1andx3.2.2.TheLLVMpassesoperateontheLLVMintermediaterepresentation(IR),whichisalow-levelstrongly-typedlanguage-independentprogramrep-resentationtailoredforstaticanalysesandoptimizationpurposes.TheLLVMIRisgeneratedfromtheC/C++sourcecodebyclang,whichpreservesmostofthetypeinformationthatisrequiredbyouranalysis,withafewcornercases.Forexample,incertaincases,clangdoesnotpreservetheoriginaltypesofpointersthatarecasttovoid*whenpassingthemasanargumenttomemsetorsimilarfunctions,whichisrequiredforthememset-relatedoptimizationsdiscussedinx3.2.2.TheIRalsodoesnotdistinguishbetweenvoid*andchar*(representsbothasi8*),butthisinformationisrequiredforourstringpointersdetectionheuristic.Weaugmentedclangtoal-wayspreservesuchtypeinformationasLLVMmetadata.Safestackinstrumentationpass:Thesafestackinstru-mentationtargetsfunctionsthatcontainon-stackmem-oryobjectsthatcannotbeputonthesafestack.Forsuchfunctions,itallocatesastackframeontheunsafestackandrelocatescorrespondingvariablestothatframe.Giventhatmostofthefunctionsdonotneedanun-safestack,Leveeusestheusualstackpointer(rspreg-isteronx86-64)asthesafestackpointer,andstorestheunsafestackpointerinthethreadcontrolblock,whichisaccessibledirectlythroughoneofthesegmentregisters.Whenneeded,theunsafestackpointerisloadedintoanIRlocalvalue,andLeveereliesontheLLVMregisterallocatortopicktheregisterfortheunsafestackpointer.LeveeexplicitlyencodesunsafestackoperationsasIRinstructionsthatmanipulateanunsafestackpointer;itleavesalloperationsthatuseasafestackintact,lettingtheLLVMcodegeneratormanagethem.Leveeperformsthesechangesasalaststepbeforecodegeneration(di-rectlyreplacingLLVM'sstack-cookieprotectionpass),thusensuringthatitoperatesonthenalstacklayout.Certainlow-levelfunctionsmodifythestackpointerdirectly.Thesefunctionsincludesetjmp/longjmpandexceptionhandlingfunctions(whichstore/loadthestackpointer),andthreadcreate/destroyfunctions,whichal-locate/freestacksforthreads.OnFreeBSDweprovide7 Figure4:PerformanceoverheadsonFreeBSD(Phoronix).existsuccessfulattacksagainstCFI[19,15,9].WhileneitheroftheseattacksarepossibleagainstCPIbycon-struction,wefoundthat,inpractice,neitherofthemwouldworkagainstCPSeither.Wefurtherdiscusscon-ceptualdifferencesbetweenCFIandCPIinx6.5.3CaseStudy:ASafeFreeBSDDistributionHavingshownthatLeveeisbotheffectiveandefcient,wenowevaluatethefeasibilityofusingLeveetoprotectanentireoperatingsystemdistribution,namelyFreeBSD10.Werebuiltthebasesystem—baselibraries,devel-opmenttools,andserviceslikebindandopenssh—plusmorethan100packages(includingapache,postgresql,php,python)infourcongurations:CPI,CPS,SafeStack,andvanilla.FreeBSD10usesLLVM/clangasitsdefaultcompiler,whilesomecorecomponentsofLinux(e.g.,glibc)cannotbebuiltwithclangyet.WeintegratedtheCPIruntimedirectlyintotheClibraryandthethread-inglibrary.Wehavenotyetportedtheruntimetokernelspace,sotheOSkernelremaineduninstrumented.WeevaluatedtheperformanceofthesystemusingthePhoronixtestsuite[41],awidelyusedcomprehensivebenchmarkingplatformforoperatingsystems.Wechosethe“server”settingandexcludedbenchmarksmarkedasunsupportedorthatdonotcompileorrunonrecentFreeBSDversions.AllbenchmarksthatcompiledandworkedonvanillaFreeBSDalsocompiledandworkedintheCPI,CPSandSafeStackversions.Fig.4showstheoverheadofCPI,CPSandthesafe-stackversionscomparedtothevanillaversion.TheresultsareconsistentwiththeSPECresultspresentedinx5.2.ThePhoronixbenchmarksexerciselargepartsofthesystemandsomeofthemaremulti-threaded,whichintroducessignicantvarianceintheresults,especiallywhenrunonmodernhardware.AsFig.4shows,formanybenchmarkstheoverheadsofCPSandthesafestackarewithinthemeasurementerror.Benchmark SafeStackCPSCPI Staticpage 1.7%8.9%16.9%Wsgitestpage 1.0%4.0%15.3%Dynamicpage 1.4%15.9%138.8%Table4:Throughputbenchmarkforwebserverstack(FreeBSD+Apache+SQLite+mod wsgi+Python+Django).WealsoevaluatedarealisticusagemodeloftheFreeBSDsystemasawebserver.WeinstalledMezza-nine,acontentmanagementsystembasedonDjango,whichusesPython,SQLite,Apache,andmod wsgi.WeusedtheApacheabtooltobenchmarkthethroughputofthewebserver.TheresultsaresummarizedinTable4.TheCPIoverheadforadynamicpagegeneratedbyPythoncodeismuchlargerthenweexpected,butcon-sistentwithsuspiciouslyhighoverheadofthepybenchbenchmarkinFig.4.WethinkitmightbecausedbytheuseofsomeCconstructsinthePythoninterpreterthatarenotyethandledwellbyouroptimizationheuristics,e.g.,emulatingC++inheritanceinC.Webelievetheper-formancemightbeimprovedinthiscasebyextendingtheheuristicstorecognizesuchCconstructs.6RelatedWorkAvarietyofdefensemechanismshavebeenproposedto-datetoanswertheincreasingchallengeofcontrol-owhijackattacks.Fig.5comparesthedesignofthedifferentprotectionapproachestoourapproach.Enforcingmemorysafetyensuresthatnodanglingorout-of-boundspointerscanbereadorwrittenbytheap-plication,thuspreventingtheattackinitsrststep.Cy-clone[25]andCCured[36]extendCwithasafetypesystemtoenforcememorysafetyfeatures.Theseap-proachesfacetheproblemthatthereisalarge(unported)legacycodebase.Incontrast,CPIandCPSbothworkforunmodiedC/C++code.SoftBound[34]withitsCETS[35]extensionenforcescompletememorysafetyatthecostof2–4slowdown.Toolswithlessover-head,likeBBC[4],onlyapproximatememorysafety.LBC[20]andAddressSanitizer[43]detectcontinu-ousbufferoverowsand(probabilistically)indexinger-rors,butcanbebypassedbyanattackerwhoavoidstheredzonesplacedaroundobjects.Writeintegritytesting(WIT)[3]providesspatialmemorysafetybyrestrictingpointerwritesaccordingtopoints-tosetsobtainedbyanover-approximatestaticanalysis(andisthereforelimitedbythestaticanalysis).Othertechniques[17,2]enforcetype-safememoryreusetomitigateattacksthatexploittemporalerrors(useafterfrees).CPIbydesignenforcesspatialandtemporalmemorysafetyforasubsetofdata(codepointers)inStep2ofFig.5.OurLeveeprototypecurrentlyenforcesspatialmemorysafetyandmaybeextendedtoenforcetemporalmemorysafetyaswell(e.g.,howCETSextendsSoft-11 Figure5:Summaryofcontrol-owhijackdefensemechanismsalignedwithindividualstepsthatarenecessaryforasuccessfulattack.Thegureontheleftisasimpliedversionofthecompletememorycorruptiondiagramin[46].Bound).WebelieveCPIisthersttostopallcontrol-owhijackattacksatthisstep.Randomizationtechniques,likeASLR[40]andASLP[26],mitigateattacksbyrestrictingtheattacker'sknowledgeofthememorylayoutoftheapplicationinStep3.PointGuard[13]andDSR[7](whichissimilartoprobabilisticWIT)randomizethedatarepresentationbyencryptingpointervalues,butfacecompatibilityprob-lems.Softwarediversity[21]allowsne-grained,per-instancecoderandomization.Randomizationtechniquesaredefeatedbyinformationleaksthrough,e.g.,memorycorruptionbugs[45]orsidechannelattacks[22].Control-owintegrity[1]ensuresthatthetargetsofallindirectcontrol-owtransferspointtovalidcodelo-cationsinStep4.AllCFIsolutionsrelyonstaticallypre-computedcontext-insensitivesetsofvalidcontrol-owtargetlocations.ManypracticalCFIsolutionssim-plyincludeeveryfunctioninaprograminthesetofvalidtargets[53,54,29,47].Evenifprecisestaticanalysiswasbefeasible,CFIcouldnotguaranteepro-tectionagainstallcontrol-owhijackattacks,butrathermerelyrestrictthesetsofpotentialhijacktargets.In-deed,recentresults[19,15,9]showthatmanyexist-ingCFIsolutionscanbebypassedinaprincipledway.CFI+SFI[52],Strato[51]andMIPS[38]enforceanevenmorerelaxed,staticallydenedCFIpropertyinordertoenforcesoftware-basedfaultisolation(SFI).CCFI[31]encryptscodepointersinmemoryandprovidessecu-rityguaranteesclosetoCPS.Data-owbasedtechniqueslikedata-owintegrity(DFI)[10]ordynamictaintanal-ysis(DTA)[42]canenforcethattheusedcodepointerwasnotsetbyanunrelatedinstructionortountrusteddata,respectively.Thesetechniquesmaymisssomeat-tacksorcausefalsepositives,andhavehigherperfor-mancecoststhanCPIandCPS.Stackcookies,CFI,DFI,andDTAprotectcontrol-transferinstructionsbydetect-ingillegalmodicationofthecodepointerwheneveritisused,whileCPIprotectstheloadandstoreofacodepointer,thuspreventingthecorruptionintherstplace.CPIprovidespreciseandprovablesecurityguarantees.InStep5,theexecutionofinjectedcodeispreventedbyenforcingthenon-executable(NX)datapolicy,butcode-reuseattacksremainpossible.Highlevelpolicies,e.g.,restrictingtheallowedsys-temcallsofanapplication,limitthepoweroftheat-tackereveninthepresenceofasuccessfulcontrol-owhijackattackinStep6.Softwarefaultisolation(SFI)techniques[32,18,11,50,52]restrictindirectcontrol-owtransfersandmemoryaccessestopartofthead-dressspace,enforcingasandboxthatcontainstheattack.SFIpreventsanattackfromescapingthesandboxandal-lowstheenforcementofahigh-levelpolicy,whileCPIenforcesthecontrol-owinsidetheapplication.7ConclusionThispaperdescribescode-pointerintegrity(CPI),awaytoprotectsystemsagainstallcontrol-owhijacksthatexploitmemorybugs,andcode-pointerseparation,are-laxedformofCPIthatstillprovidesstrongguarantees.Thekeyideaistoselectivelyprovidefullmemorysafetyforjustasubsetofaprogram'spointers,namelycodepointers.Weimplementedourapproachandshowedthatitiseffective,efcient,andpractical.Givenitsadvan-tageoussecurity-to-overheadratio,webelieveourap-proachmarksasteptowarddeterministicallysecuresys-temsthatarefullyimmunetocontrol-owhijackattacks.AcknowledgmentsWethanktheanonymousreviewersandourshepherdJunfengYangfortheirvaluableinput.Wearegrate-fultoMartinAbadi,HerbertBos,MiguelCastro,VijayD'Silva,UlfarErlingsson,JohannesKinder,PerLarsen,JimLarus,SantoshNagarakatte,andJonasWagnerfor12 AtomicTypesa::=intjpPointerTypesp::=ajsjfjvoidStructTypess::=structf:::;ai:idi;:::gLHSExpressionslhs::=xjlhsjlhs:idjlhs��idRHSExpressionsrhs::=ij&fjrhs+rhsjlhsj&lhsj(a)rhsjsizeof(p)jmalloc(rhs)Commandsc::=c;cjlhs=rhsjf()j(lhs)()Figure6:ThesubsetofCusedinAppendixA;xdenoteslocalstaticallytypedvariables,id–structureelds,i–integers,andf–functionsfromapre-denedset.theirvaluablefeedbackanddiscussionsonearlierver-sionsofthepaper.ThisworkwassupportedbyERCStartingGrantNo.278656,aMicrosoftResearchPhDfellowship,agiftfromGoogle,DARPAawardHR0011-12-2-005,NSFgrantsCNS-0831298andCNS-1319137,andAFOSRFA9550-09-1-0539.AFormalModelofCPIThissectionpresentsaformalmodelandoperationalse-manticsoftheCPIpropertyandasketchofitscorrect-nessproof.DuetothesizeandcomplexityofC/C++specications,wefocusonasmallsubsetofCthatillus-tratesthemostimportantfeaturesofCPI.Duetospacelimitationswefocusonspatialmemorysafety.WebuildupontheformalizationofspatialmemorysafetyinSoft-Bound[34],reusethesamenotation,andextendittosupportapplyingspatialmemorysafetytoasubsetofmemorylocations.Theformalismcanbeeasilyextendedtoprovidetemporalmemorysafety,directlyapplyingtheCETS[35]mechanismtothesafememoryregionofthemodel.Fig.6givesthesyntaxrulesoftheCsubsetweconsiderinthissection.AllvalidprogramsmustalsopasstypecheckingasspeciedbytheCstandard.WedenetheruntimeenvironmentEofaprogramasatriple(S;Mu;Ms),whereSmapsvariableidentierstotheirrespectiveatomictypesandaddresses,aregu-larmemoryMumapsaddressestovalues(denotedasvandcalledregularvalues),andasafememoryMsmapsaddressestovalueswithboundsinformation(denotedasv(b;e)andcalledsafevalues)oraspecialmarkernone.Theboundsinformationspeciesthelowest(b)andthehighest(e)addressofthecorrespondingmemoryobject.MuandMsusethesameaddressing,butmightcontaindistinctvaluesforthesameaddress.Somelocations(e.g.,ofvoidtype)canstoreeithersafeorregularvalueandareresolvedtoeitherMsorMuatruntime.Theruntimeprovidestheusualsetofmemoryoper-ationsforMuandMs,assummarizedinTable5.Mumodelsstandardmemory,whereasMsstoresvalueswithboundsandhasaspecialmarkerfor“absent”locations,similarlytothememoryinSoftBound's[34]formaliza-tion.Weassumethememoryoperationsfollowthestan-dardbehaviorofread/write/mallocoperationsinallotherOperation Semantics readuMul returnMu[l]writeuMulv setMu[l]=vreadsMsl returnMs[l],iflisallocated;returnnoneotherwisewritesMslv(b;e) setMs[l]=v(b;e),iflisallocated; donothingotherwisewritesMslnone setMs[l]=none,iflisallocated; donothingotherwise mallocEi allocateamemoryobjectofsizeiinbothE:Muand E:Ms(atthesameaddress);failwhenoutofmemoryTable5:MemoryOperationsinCPIsensitiveint::=falsesensitivevoid::=truesensitivef::=truesensitivep::=sensitivepsensitives::=_i2eldsofssensitiveaiFigure7:ThedecisioncriterionforprotectingtypesinCPIrespects,e.g.,readreturnsthevaluepreviouslywrittentothesamelocation,mallocallocatesaregionofmemorythatisdisjointwithanyotherallocatedregion,etc..EnforcingtheCPIpropertywithlowperformanceoverheadrequiresplacingmostvariablesinMu,whilestillensuringthatallpointersthatrequireprotectionatruntimeaccordingtotheCPIpropertyareplacedinMs.Inthisformalization,werelyontype-basedstaticanalysisasdenedbythesensitivecriterion,shownonFig.7.Wesayatypepissensitiveiffsensitivep=true.SettingsensitivetotrueforalltypeswouldmaketheCPIoperationalsemanticsequivalenttotheonepro-videdbySoftBoundandwouldensurefullspatialmem-orysafetyofallmemoryoperationsinaprogram.Theclassicationprovidedbythesensitivecrite-rionisstaticandonlydetermineswhichoperationsinaprogramtoinstrument.Expressionsofsensitivetypescouldevaluatetobothsafeorregularvaluesatruntime,whereasexpressionsofregulartypesalwaysevaluatetoregularvalues.Inparticular,accordingtoFig.7,voidissensitiveand,hence,inagreementwiththeCspeci-cation,valuesofthattypecanholdanypointervalueatruntime,eithersafeorregular.WeextendtheSoftBounddenitionoftheresultofanoperationtodifferentiatebetweensafeandregularvaluesandleft-hand-sidelocations:Resultsr::=v(b;e)jvjlsjlujOKjOutOfMemjAbortwherev(b;e)andvarethesafe(withboundsinforma-tion)and,respectively,regularvaluesthatresultfromarighthandsideexpression,luandlsarelocationsthatre-sultfromasafeandregularleft-hand-sideexpression,OKisaresultofasuccessfulcommand,andOutOfMemandAbortareerrorcodes.Weassumethatalloperationalse-manticsrulesofthelanguagepropagatetheseerrorcodesuptotheendoftheprogramunchanged.Usingtheabovedenitions,wenowformalizetheop-13 References[1]M.Abadi,M.Budiu,U.Erlingsson,andJ.Ligatti.Control-owintegrity.InACMConf.onComputerandCommunicationSecurity,2005.[2]P.Akritidis.Cling:Amemoryallocatortomitigatedanglingpointers.InUSENIXSecuritySymposium,2010.[3]P.Akritidis,C.Cadar,C.Raiciu,M.Costa,andM.Castro.PreventingmemoryerrorexploitswithWIT.InIEEESymp.onSecurityandPrivacy,May2008.[4]P.Akritidis,M.Costa,M.Castro,andS.Hand.BaggyBoundsChecking:AnEfcientandBackwards-compatibleDefenseAgainstOut-of-boundsErrors.InUSENIXSecuritySymposium,2009.[5]G.AltekarandI.Stoica.Focusreplaydebuggingeffortonthecontrolplane.USENIXWorkshoponHotTopicsinDependability,2010.[6]S.Bhatkar,E.Bhatkar,R.Sekar,andD.C.Duvar-ney.Efcienttechniquesforcomprehensivepro-tectionfrommemoryerrorexploits.InUSENIXSecuritySymposium,2005.[7]S.BhatkarandR.Sekar.DataSpaceRandomiza-tion.InIntl.Conf.onDetectionofIntrusionsandMalware,andVulnerabilityAssessment,2008.[8]T.Bletsch,X.Jiang,V.W.Freeh,andZ.Liang.Jump-orientedprogramming:anewclassofcode-reuseattack.InACMSymp.onInformation,Com-puterandCommunicationsSecurity,2011.[9]N.CarliniandD.Wagner.Ropisstilldangerous:Breakingmoderndefenses.InUSENIXSecuritySymposium,2014.[10]M.Castro,M.Costa,andT.Harris.Securingsoft-warebyenforcingdata-owintegrity.InSymp.onOperatingSystemsDesignandImplementation,2006.[11]M.Castro,M.Costa,J.-P.Martin,M.Peinado,P.Akritidis,A.Donnelly,P.Barham,andR.Black.Fastbyte-granularitysoftwarefaultisolation.InACMSymp.onOperatingSystemsPrinciples,2009.[12]S.Checkoway,L.Davi,A.Dmitrienko,A.-R.Sadeghi,H.Shacham,andM.Winandy.Return-orientedprogrammingwithoutreturns.InACMConf.onComputerandCommunicationSecurity,2010.[13]C.Cowan,S.Beattie,J.Johansen,andP.Wa-gle.PointguardTM:protectingpointersfrombufferoverowvulnerabilities.InUSENIXSecuritySym-posium,2003.[14]C.Cowan,C.Pu,D.Maier,H.Hintony,J.Walpole,P.Bakke,S.Beattie,A.Grier,P.Wagle,andQ.Zhang.StackGuard:Automaticadaptivedetec-tionandpreventionofbuffer-overowattacks.InUSENIXSecuritySymposium,1998.[15]L.Davi,A.-R.Sadeghi,D.Lehmann,andF.Mon-rose.Stitchingthegadgets:Ontheineffectivenessofcoarse-grainedcontrol-owintegrityprotection.InUSENIXSecuritySymposium,2014.[16]J.Devietti,C.Blundell,M.M.K.Martin,andS.Zdancewic.Hardbound:Architecturalsupportforspatialsafetyofthecprogramminglanguage.InIntl.Conf.onArchitecturalSupportforProgram-mingLanguagesandOperatingSystems,2008.[17]D.Dhurjati,S.Kowshik,andV.Adve.SAFE-Code:enforcingaliasanalysisforweaklytypedlanguages.SIGPLANNotices,41(6):144–157,June2006.[18]´U.Erlingsson,M.Abadi,M.Vrable,M.Budiu,andG.C.Necula.XFI:Softwareguardsforsystemad-dressspaces.InSymp.onOperatingSystemsDe-signandImplementation,2006.[19]E.G¨oktas¸,E.Athanasopoulosy,H.Bos,andG.Por-tokalidis.Outofcontrol:Overcomingcontrol-owintegrity.InIEEESymp.onSecurityandPrivacy,2014.[20]N.Hasabnis,A.Misra,andR.Sekar.Light-weightboundschecking.InIEEE/ACMSymp.onCodeGenerationandOptimization,2012.[21]A.Homescu,S.Neisius,P.Larsen,S.Brunthaler,andM.Franz.Prole-guidedautomatedsoftwarediversity.InIEEE/ACMSymp.onCodeGenerationandOptimization,2013.[22]R.Hund,C.Willems,andT.Holz.Practicaltimingsidechannelattacksagainstkernelspaceaslr.InIEEESymp.onSecurityandPrivacy,2013.[23]IntelArchitectureInstructionSetExten-sionsProgrammingReference.http://download-software.intel.com/sites/default/files/319433-015.pdf,2013.[24]Intel.IntroductiontoIntelmemoryprotec-tionextensions.https://software.intel.com/en-us/articles/introduction-to-intel-memory-protection-extensions,July2013.15