structtun_struct*tun=...;structsock*sk=−tun-sk;if(!tun)returnPO - PDF document

structtun_struct*tun=...;structsock*sk=−tun-sk;if(!tun)returnPOLLERR;/*writetoaddressbasedontun*/ Figure2:Anullpointerdereferencevulnerability(CVE-2009-1897)intheLinuxkernel,wherethedereferenceofpointertunisbeforethenullpointercheck.Thecodebecomesexploitableasgccoptimizesawaythenullpointercheck[10].beforethenullpointercheck!tun.Normally,thekernelforbidsaccesstopagezero;anulltunpointingtopagezerocausesakerneloopsat−tun-skandterminatesthecurrentprocess.Evenifpagezeroismadeaccessible(e.g.,viammaporsomeotherexploits[25,45]),thecheck!tunwouldcatchanulltunandpreventanyfurtherexploits.Ineithercase,anadversaryshouldnotbeabletogobeyondthenullpointercheck.Unfortunately,unstablecodecanturnthissimplebugintoanexploitablevulnerability.Forexample,whengccrstseesthedereference−tun-sk,itconcludesthatthepointertunmustbenon-null,becausetheCstandardstatesthatdereferencinganullpointerisundened[24:§6.5.3].Sincetunisnon-null,gccfurtherdeterminesthatthenullpointercheckisunnecessaryandeliminatesthecheck,makingaprivilegeescalationexploitpossiblethatwouldnototherwisebe[10].Poorunderstandingofunstablecodeisamajorobstacletoreasoningaboutsystembehavior.Forprogrammers,compilersthatdiscardunstablecodeareoften“baing”and“makenosense”[46],merelygcc's“creativereinter-pretationofbasicCsemantics”[27].Ontheotherhand,compilerwritersarguethattheCstandardallowssuchoptimizations,whichmanycompilersexploit(see§2.3);itisthe“brokencode”[17]thatprogrammersshouldx.Whoisrightinthisdebate?Fromthecompiler'spointofview,theprogrammersmadeamistakeintheircode.Forexample,Figure2clearlycontainsabug,andevenFigure1isarguablyincorrectgivenastrictinterpretationoftheCstandard.However,thesebugsarequitesubtle,andunderstandingthemrequiresdetailedknowledgeofthelanguagespecication.Thus,itisnotsurprisingthatsuchbugscontinuetoproliferate.Fromtheprogrammer'spointofview,thecompilersarebeingtooaggressivewiththeiroptimizations.However,optimizationsareimportantforachievinggoodperfor-mance;manyoptimizationsfundamentallyrelyontheprecisesemanticsoftheClanguage,suchaseliminatingneedlessnullpointerchecksoroptimizingintegerloopvariables[20,29].Thus,itisdicultforcompilerwriterstodistinguishlegalyetcomplexoptimizationsfromanop-timizationthatgoestoofarandviolatestheprogrammer'sintent[29:§3].Thispaperhelpsresolvethisdebatebyintroducingamodelforidentifyingunstablecodethatallowsacom-pilertogenerateprecisewarningswhenitremovescodebasedonundenedbehavior.Themodelspeciespreciseconditionsunderwhichacodefragmentcaninduceun-denedbehavior.Usingtheseconditionswecanidentifyfragmentsthatcanbeeliminatedundertheassumptionthatundenedbehaviorisnevertriggered;specically,anyfragmentthatisreachableonlybyinputsthattriggerundenedbehaviorisunstablecode.Wemakethismodelmoreprecisein§3.TheStackcheckerimplementsthismodeltoidentifyunstablecode.FortheexampleinFigure2,itemitsawarningthatthenullpointercheck!tunisunstableduetotheearlierdereference−tun-sk.Stackrstcomputestheundenedbehaviorconditionsforawiderangeofcon-structs,includingpointerandintegerarithmetic,memoryaccess,andlibraryfunctioncalls.Itthenusesaconstraintsolver[3]todeterminewhetherthecodecanbesimpliedawaygiventheundenedbehaviorconditions,suchaswhetherthecodeisreachableonlywhentheundenedbe-haviorconditionsaretrue.WehopethatStackwillhelpprogrammersndunstablecodeintheirapplications,andthatourmodelwillhelpcompilersmakebetterdecisionsaboutwhatoptimizationsmightbeunsafeandwhenanoptimizershouldproduceawarning.WeimplementedtheStackcheckerusingtheLLVMcompilerframework[30]andtheBoolectorsolver[3].Applyingittoawiderangeofsystemsuncovered160newbugs,whichwereconrmedandxedbythedevelopers.Wealsoreceivedpositivefeedbackfromoutsideuserswho,withthehelpofStack,xedadditionalbugsinbothopen-sourceandcommercialcodebases.Ourexperienceshowsthatunstablecodeisawidespreadthreatinsystems,thatanadversarycanexploitvulnerabilitiescausedbyunstablecodewithmajorcompilers,andthatStackisusefulforidentifyingunstablecode.Themaincontributionsofthispaperare:anewmodelforunderstandingunstablecode,astaticcheckerforidentifyingunstablecode,andadetailedcasestudyofunstablecodeinrealsystems.Anotherconclusiononecandrawfromthispaperisthatlanguagedesignersshouldbecarefulwithdeninglanguageconstructasundenedbehavior.Almosteverylanguageallowsadevelopertowriteprogramsthathaveundenedmeaningaccordingtothelanguagespecica-tion.OurexperiencewithC/C++indicatesthatbeingliberalwithwhatisundenedcanleadtosubtlebugs.Therestofthepaperisorganizedasfollows.§2pro-videsbackgroundinformation.§3presentsourmodelofunstablecode.§4outlinesthedesignofStack.§5sum-marizesitsimplementation.§6reportsourexperienceofapplyingStacktoidentifyunstablecodeandevaluatesStack'stechniques.§7coversrelatedwork.§8concludes.2 ConstructSucientconditionUndenedbehavior Languagep+xp1+x1[0;2n�1]pointeroverowpp=NULLnullpointerdereferencexopsyx1opsy1[�2n�1;2n�1�1]signedintegeroverowx/y,x%yy=0divisionbyzeroxy,x&#x]TJ/;&#x 8.9;٤ ;&#xTf 1;�.61;
0 ;&#xTd [;&#x]TJ/;&#x 8.9;٤ ;&#xTf 1;�.61;
0 ;&#xTd [;yy0_ynoversizedshifta[x]x0_xARRAY_SIZE(a)bueroverowLibraryabs(x)x=�2n�1absolutevalueoverowmemcpy(dst;src;len)jdst�srcjlenoverlappingmemorycopyuseqafterfree(p)alias(p;q)useafterfreeuseqafterp0Brealloc(p;:::)alias(p;q)^p0,NULLuseafterrealloc Figure3:Alistofsucient(thoughnotnecessary)conditionsforundenedbehaviorincertainCconstructs[24:§J.2].Herep;p0;qaren-bitpointers;x;yaren-bitintegers;aisanarray,thecapacityofwhichisdenotedasARRAY_SIZE(a);opsreferstobinaryoperators+;-;*;/;%oversignedintegers;x1meanstoconsiderxasinnitelyranged;NULListhenullpointer;alias(p;q)predicateswhetherpandqpointtothesameobject.2BackgroundThissectionprovidessomebackgroundonundenedbe-haviorandhowitcanleadtounstablecode.Itbuildsonearliersurveys[26,41,49]andblogposts[29,39,40]thatdescribeunstablecodeexamples,andextendsthembyinvestigatingtheevolutionofoptimizationsincompilers.2.1UndenedbehaviorFigure3showsalistofconstructsandtheirundenedbe-haviorconditions,asspeciedintheCstandard[24:§J.2].Onecategoryofundenedbehaviorissimplyprogram-mingerrors,suchasnullpointerdereference,buerover-ow,anduseafterfree.Theothercategoryisnon-portableconstructs,thehardwareimplementationsofwhichoftenhavesubtledierences.Forinstance,whensignedintegeroverowordivisionbyzerooccurs,adivisioninstructiontrapsonx86[22:§3.2],whileitsilentlyproducesanundenedresultonPowerPC[21:§3.3.8].Anotherexampleisshiftinstruc-tions:left-shiftinga32-bitoneby32bitsproduces0onARMandPowerPC,but1onx86;however,left-shiftinga32-bitoneby64bitsproduces0onARM,but1onx86andPowerPC.Wangetal.'ssurvey[49]providesmoredetailsofsucharchitecturaldierences.Tobuildaportablesystem,thelanguagestandardcouldimposeuniformbehaviorovererroneousornon-portableconstructs,asmanyhigher-levellanguagesdo.Indoingso,thecompilerwouldhavetosynthesizeextrainstruc-tions.Forexample,toenforcewell-denederrorhan-dling(e.g.,run-timeexception)onbueroverow,thecompilerwouldneedtoinsertextraboundschecksformemoryaccessoperations.Similarly,toenforceaconsis-tentshiftbehavioronx86,foreveryxythecompilerwouldneedtoinsertacheckagainsty(unlessitisabletoprovethatyisnotoversized),asfollows:if(y0_yn)then0elsexy:TheC-familylanguagesemployadierentapproach.Aimingforsystemprogramming,theirspecicationschoosetotrustprogrammers[23:§0]andassumethattheircodewillneverinvokeundenedbehavior.Thisassumptiongivesmorefreedomtothecompilerthansimplysayingthattheresultofaparticularoperationisarchitecture-dependent.Whileitallowsthecompilertogenerateecientcodewithoutextrachecks,theassump-tionalsoopensthedoortounstablecode.2.2ExamplesofunstablecodeThetoprowofFigure4showssixrepresentativeexamplesofunstablecodeintheformofsanitychecks.Allofthesechecksmayevaluatetofalseandbecomedeadcodeunderoptimizations,eventhoughnoneappeartodirectlyinvokeundenedbehavior.Wewillusethemtotestexistingcompilersin§2.3.Thecheckp+100presemblesFigure1,whichisdeadassumingnopointeroverow.Thenullpointercheck!pwithanearlierdereferenceisfromFigure2,whichisdeadassumingnonullpointerdereference.Thecheckx+100xwithasignedintegerxbecomesdeadassumingnosignedintegeroverow.ItonceledtoaharshdebatebetweensomeCprogrammersandgccdevelopers[17].Anothercheckx++1000testswhetheroptimizationsperformmoreelaboratereasoningassumingnosignedintegeroverow;x+isknowntobepositive.Theshiftcheck!(1x)wasintendedtocatchalargex,fromapatchtotheext4lesystem[31].Itbecomesdeadassumingnooversizedshiftamount.Thecheckabs(x)0wasusedinthePHPinterpretertocatchthemostnegativevalue(i.e.,�2n�1).Itbecomesdeadwhenoptimizationsunderstandthislibraryfunctionandassumenoabsolutevalueoverow[18].3 3.1UnstablecodeToformalizeaprogrammer'smisunderstandingoftheCspecicationthatleadstounstablecode,letC?denoteaCdialectthatassignswell-denedsemanticstocodefragmentsthathaveundenedbehaviorinC.Forexample,C?isdenedforaataddressspace,anullpointerthatmapstoaddresszero,andwrap-aroundsemanticsforpointerandintegerarithmetic[38].AcodefragmenteisastatementorexpressionataparticularsourcelocationinprogramP.IfthecompilercantransformthefragmenteinawaythatwouldchangeP'sbehaviorunderC?butnotunderC,theneisunstablecode.LetP[e=e0]beaprogramformedbyreplacingewithsomefragmente0atthesamesourcelocation.WhenisitlegalforacompilertotransformPintoP[e=e0],denotedasP{P[e=e0]?Inalanguagespecicationwithoutundenedbehavior,theanswerisstraightforward:itislegalifforeveryinput,bothPandP[e=e0]producethesameresult.Inalanguagespecicationwithundenedbehavior,theanswerismorecomplicated;namely,itislegalifforeveryinput,oneofthefollowingistrue:bothPandP[e=e0]producethesameresultswithoutinvokingundenedbehavior,orPinvokesundenedbehavior,inwhichcaseitdoesnotmatterwhatP[e=e0]does.Usingthisnotation,wedeneunstablecodebelow.Denition1(Unstablecode).Acodefragmenteinpro-gramPisunstablew.r.t.languagespecicationsCandC?ithereexistsafragmente0suchthatP{P[e=e0]islegalunderCbutnotunderC?.Forexample,forthesanitycheckslistedinFigure4,aCcompilerisentitledtoreplacethemwithfalse,asthisislegalaccordingtotheCspecication,whereasahypotheticalC?compilercannotdothesame.Therefore,thesechecksareunstablecode.3.2ApproachforidentifyingunstablecodeTheabovedenitioncaptureswhatunstablecodeis,butdoesnotprovideawayofndingunstablecode,becauseitisdiculttoreasonabouthowanentireprogramwillbehave.Asaproxyforachangeinprogrambehavior,StacklooksforcodethatcanbetransformedbysomeoptimizerOunderCbutnotunderC?.Inparticular,Stackdoesthisusingatwo-phasescheme:1.runOwithouttakingadvantageofundenedbehavior,whichresemblesoptimizationsunderC?;and2.runOagain,thistimetakingadvantageofundenedbehavior,whichresembles(moreaggressive)optimiza-tionsunderC.IfOoptimizesextracodeinthesecondphase,weassumethereasonOdidnotdosointherstphaseisbecauseitwouldhavechangedtheprogram'ssemanticsunderC?,andsoStackconsidersthatcodetobeunstable.Stack'soptimizer-basedapproachtondingunstablecodewillmissunstablecodethataspecicoptimizercannoteliminateinthesecondphase,evenifthereexistssomeoptimizerthatcould.Thisapproachwillalsogener-atefalsereportsiftheoptimizerisnotaggressiveenoughineliminatingcodeintherstphase.Thus,onechallengeinStack'sdesigniscomingupwithanoptimizerthatissucientlyaggressivetominimizetheseproblems.Inorderforthisapproachtowork,Stackrequiresanoptimizerthatcanselectivelytakeadvantageofunde-nedbehavior.Tobuildsuchoptimizers,weformalizewhatitmeansto“takeadvantageofundenedbehav-ior”in§3.2.1,byintroducingthewell-denedprogramassumption,whichcapturesC'sassumptionthatprogram-mersneverwriteprogramsthatinvokeundenedbehavior.Givenanoptimizerthatcantakeexplicitassumptionsasinput,Stackcanturnon(oro)optimizationsbasedonundenedbehaviorbysupplying(ornot)thewell-denedprogramassumptiontotheoptimizer.Webuildtwoag-gressiveoptimizersthatfollowthisapproach:onethateliminatesunreachablecode(§3.2.2)andonethatsimpli-esunnecessarycomputation(§3.2.3).3.2.1Well-denedprogramassumptionWeformalizewhatitmeanstotakeadvantageofunde-nedbehaviorinanoptimizerasfollows.Consideraprogramwithinputx.Givenacodefragmente,letRe(x)denoteitsreachabilitycondition,whichistrueiewillexecuteunderinputx;andletUe(x)denoteitsundenedbehaviorcondition,orUBconditionforshort,whichin-dicateswhethereexhibitsundenedbehavioroninputx,assumingCsemantics(seeFigure3).BothRe(x)andUe(x)arebooleanexpressions.Forexample,givenapointerdereferencepinexpressione,oneUBconditionUe(x)isp=NULL(i.e.,causinganullpointerdereference).Intuitively,inawell-denedprogramtodereferencepointerp,pmustbenon-null.Inotherwords,thenega-tionofitsUBcondition,p,NULL,mustholdwhenevertheexpressionexecutes.Wegeneralizethisbelow.Denition2(Well-denedprogramassumption).Acodefragmenteiswell-denedonaninputxiexecutingenevertriggersundenedbehaviorate:Re(x)!:Ue(x):(1)Furthermore,aprogramiswell-denedonaninputieveryfragmentoftheprogramiswell-denedonthatinput,denotedas
:
(x)=^e2PRe(x)!:Ue(x):(2)5 Compilerfrontend(§4.2) UBconditioninsertion(§4.3) Solver-basedoptimization(§4.4) Bugreportgeneration(§4.5) C IR Figure7:Stack'sworkow.ItinvokesclangtoconvertaC/C++programintoLLVMIR,andthendetectsunstablecodebasedontheIR.Clearly,thisissatisable.Thebooleanoraclethenpro-posesfalse.Thistimethesimplicationqueryis:(p+100p),false^true^(true!:(p1+1001[0;2n�1])):Sincethereisnopointerpthatsatisesthisquery,onecanfoldp+100pintofalse.§6.2.2willshowmoreex-amplesofidentifyingunstablecodeusingsimplication.Withtheabovedenitionitisstraightforwardtocon-structanalgorithmtoidentifyunstablecodeduetosimpli-cation(seeFigure6).Thealgorithmconsultsanoracleforeverypossiblesimplerforme0forexpressione.Simi-larlytoelimination,itwarnsifitndse0thatisequivalenttoeonlywiththewell-denedprogramassumption.3.3DiscussionThemodelfocusesondiscardingunstablecodebyex-ploringtwobasicoptimizations,eliminationbecauseofunreachabilityandsimplicationbecauseofunnecessarycomputation.Itispossibletoexploitthewell-denedpro-gramassumptioninotherforms.Forexample,insteadofdiscardingcode,someoptimizationsreorderinstructionsandproduceunwantedcodeduetomemoryaliasing[47]ordataraces[2],whichStackdoesnotmodel.Stackimplementstwooracles,booleanandalgebra,forproposingnewexpressionsforsimplication.Onecanextenditbyintroducingneworacles.4DesignThissectiondescribesthedesignoftheStackcheckerthatdetectsunstablecodebymimickinganaggressivecompiler.AchallengeindesigningStackistomakeitscaletolargeprograms.Toaddressthischallenge,Stackusesvariantsofthealgorithmspresentedin§3thatworkonindividualfunctions.Afurtherchallengeistoavoidreportingfalsewarningsforunstablecodethatisgeneratedbythecompileritself,suchasmacrosandinlinedfunctions.4.1OverviewStackworksinfourstages,asillustratedinFigure7.Intherststage,auserprependsascriptstack-buildtotheactualbuildingcommand,suchas:%stack-buildmakeThescriptstack-buildinterceptsinvocationstogccandinvokesclanginsteadtocompilesourcecodeintotheLLVMintermediaterepresentation(IR).TheremainingthreestagesworkontheIR.Inthesecondstage,StackinsertsUBconditionslistedinFigure3intotheIR.Inthethirdstage,itperformsasolver-basedoptimizationusingavariantofthealgo-rithmsdescribedin§3.2.Inthefourthstage,Stackgen-eratesabugreportofunstablecodediscardedbythesolver-basedoptimization,withthecorrespondingsetofUBconditions.Forexample,forFigure2Stacklinksthenullpointercheck!tuntotheearlierpointerderefer-ence&#x]TJ/;&#x 9.9;ئ ;&#xTf 9;&#x.851;&#x 0 T; [0;tun-sk.4.2CompilerfrontendStackinvokesclangtocompileC-familysourcecodetotheLLVMIRfortherestofthestages.Furthermore,todetectunstablecodeacrossfunctions,itinvokesLLVMtoinlinefunctions,andworksonindividualfunctionsafterwardsforbetterscalability.AchallengeisthatStackshouldfocusonunstablecodewrittenbyprogrammers,andignorecodegeneratedbythecompiler(e.g.,frommacrosandinlinefunctions).Considerthecodesnippetbelow:#defineIS_A(p)(p!=NULL&&&#x]TJ/;&#x 9.9;ئ ;&#xTf 9;&#x.851;&#x 0 T; [0;p-tag==TAG_A)&#x]TJ/;&#x 9.9;ئ ;&#xTf 9;&#x.851;&#x 0 T; [0;p-tag==...;if(IS_A(p))...;Assumepisapointerpassedfromthecaller.Ideally,Stackcouldinspectthecallersandcheckwhetherpcanbenull.However,Stackcannotdothisbecauseitworksonindividualfunctions.Stackwouldconsiderthenullpointercheckp!=NULLunstableduetotheearlierderef-erence&#x]TJ/;&#x 9.9;ئ ;&#xTf 9;&#x.851;&#x 0 T; [0;p-tag.Inourexperience,thiscausesalargenumberoffalsewarnings,becauseprogrammersdonotdirectlywritethenullpointercheckbutsimplyreusethemacroIS_A.Toreducefalsewarnings,Stackignoressuchcompiler-generatedcodebytrackingcodeorigins,atthecostofmissingpossiblebugs(see§4.6).Todoso,Stackimplementsaclangplugintorecordtheoriginalmacroformacro-expandedcodeintheIRduringpreprocessingandcompilation.Similarly,itrecordstheoriginalfunctionforinlinedcodeintheIRduringinlin-ing.Thenalstageusestherecordedorigininformationtoavoidgeneratingbugreportsforcompiler-generatedunstablecode(see§4.5).4.3UBconditioninsertionStackimplementstheUBconditionslistedinFigure3.ForeachUBcondition,StackinsertsaspecialfunctioncallintotheIRatthecorrespondinginstruction:voidbug_on(boolexpr);7 ThisfunctiontakesonebooleanargumentastheUBcon-ditionoftheinstruction.ItisstraightforwardtorepresentUBconditionsasabooleanargumentintheIR.Forexample,foradivi-sionx=y,Stackinsertsbug_on(y=0)fordivisionbyzero.Thenextstageusesthesebug_oncallstocomputethewell-denedprogramassumption.4.4Solver-basedoptimizationTodetectunstablecode,Stackrunsthealgorithmsde-scribedin§3.2inthefollowingorder:elimination,simplicationwiththebooleanoracle,andsimplicationwiththealgebraoracle.Toimplementthesealgorithms,StackconsultstheBoolectorsolver[3]todecidesatisabilityforeliminationandsimplicationqueries,asshownin(3)and(4).BothqueriesneedtocomputethetermsRe(x)^
(x).However,itispracticallyinfeasibletopreciselycomputethemforlargeprograms.Bydenition,computingthereachabilityconditionRe(x)requiresinspectingallpathsfromthestartoftheprogram,andcomputingthewell-denedprogramassumption
(x)requiresinspectingtheentireprogramforUBconditions.Neitherscalestoalargeprogram.Toaddressthischallenge,Stackcomputesapproximatequeriesbylimitingthecomputationtoasinglefunction.Todescribetheimpactofthischange,weusethefol-lowingtwoterms.First,letR0e(x)denotefragmente'sreachabilityconditionfromthestartofcurrentfunction;StackreplacesRe(x)withR0e.Second,letdom(e)denotee'sdominators[35:§7.3],thesetoffragmentsthatev-eryexecutionpathreachingemusthavereached;Stackreplacesthewell-denedprogramassumption
(x)overtheentireprogramwiththatoverdom(e).Withthesetermswedescribethevariantofthealgo-rithmsforidentifyingunstablecodebycomputingap-proximatequeries.Stackeliminatesfragmenteifthefollowingqueryisunsatisable:R0e(x)^^d2dom(e):Ud(x):(5)Similarly,Stacksimplieseintoe0ifthefollowingqueryisunsatisable:e(x),e0(x)^R0e(x)^^d2dom(e):Ud(x):(6)AppendixAprovidesaproofthatusingbothapproximatequeriesstillcorrectlyidentiesunstablecode.Stackcomputestheapproximatequeriesasfollows.TocomputethereachabilityconditionR0e(x)withincurrentfunction,StackusesTuandPadua'salgorithm[48].TocomputetheUBconditionVd2dom(e):Ud(x),Stackcol-lectsthemfromthebug_oncallswithine'sdominators.1:procedureMinUBCond(Qeh=H^Vd2dom(e):Ud(x)i)2:ubset ?3:foralld2dom(e)do4:Q0e H^Vd02dom(e)nfdg:Ud0(x)5:ifQ0eisSATthen6:ubset ubset[fUdg7:returnubset Figure8:AlgorithmforcomputingtheminimalsetofUBcondi-tionsthatleadtounstablecodegivenqueryQeforfragmente.4.5BugreportgenerationStackgeneratesabugreportforunstablecodebasedonthesolver-basedoptimization.First,itinspectstherecordedoriginofeachunstablecodecaseintheIR,andignorescodethatisgeneratedbythecompiler,ratherthanwrittenbytheprogrammer.Tohelpusersunderstandthebugreport,StackreportstheminimalsetofUBconditionsthatmakeeachreport'scodeunstable[8],usingthefollowinggreedyalgorithm.LetQebethequerywithwhichStackdecidedthatfragmenteisunstable.ThequeryQethenmustbeunsat-isable.From(5)and(6),weknowthatthequerymustbeinthefollowingform:Qe=H^^d2dom(e):Ud(x):(7)Hdenotestheterm(s)excludingVd2dom(e):Ud(x)inQe.ThegoalistondtheminimalsetofUBconditionsthathelpmakeQeunsatisable.Todoso,StackmasksouteachUBconditionine'sdominatorsfromQeindividuallytoformanewqueryQ0e;ifthenewqueryQ0ebecomessatisable,thentheUBconditionmaskedoutiscrucialformakingfragmenteunstable.ThecompletealgorithmislistedinFigure8.4.6LimitationsThelistofundenedbehaviorStackimplements(seeFig-ure3)isincomplete.Forexample,itmissesviolationsofstrictaliasing[24:§6.5]andusesofuninitializedvari-ables[24:§6.3.2.1].Wedecidednottoimplementthembecausegccalreadyissuesdecentwarningsforbothcases.ItwouldbeeasytoextendStacktodosoaswell.Moreover,sinceourfocusistondsubtlecodechangesduetooptimizations,wechoosenottoimplementunde-nedbehaviorthatoccursinthefrontend.Oneexampleisevaluating(x=1)+(x=2);thisfragmenthasun-denedbehaviordueto“unsequencedsideeects”[24:§6.5/p2].Webelievethatthefrontendratherthantheoptimizershouldbeabletowarnagainstsuchcases.Asdiscussedin§4.4,Stackimplementsapproximationalgorithmsforbetterscalability,usingapproximatereach-abilityandUBconditions.Stackmaymissunstablecodeduetotheseapproximations.AsStackconsultsacon-straintsolverwitheliminationandsimplicationqueries,8 int64_targ1=...;int64_targ2=...;if(arg2==0)ereport(ERROR,...);int64_tresult=arg1/arg2;if(arg2==-1&&arg10&&result0)ereport(ERROR,...); Figure10:AninvalidsigneddivisionoverowcheckinPostgres,wherethedivisionprecedesthecheck.AmaliciousSQLquerywillcrashitonx86-64byexploitingsigneddivisionoverow.allyclassifyStack'sbugreportsintothefollowingfourcategoriesbasedontheimpact:non-optimizationbugs,causingproblemsregardlessofoptimizations;urgentoptimizationbugs,whereexistingcompilersareknowntocauseproblemswithoptimizationsturnedon,butnotwithoptimizationsturnedo;timebombs,wherenoknowncompilerslistedin§2.3causeproblemswithoptimizations,thoughStackdoesandfuturecompilersmaydosoaswell;andredundantcode:falsewarnings,suchasuselesschecksthatcompilerscansafelydiscard.TherestofthissubsectionillustrateseachcategoryusingexamplesfromStack'sbugreports.Allthebugsde-scribednextwerepreviouslyunknownbutnowhavebeenconrmedandxedbythecorrespondingdevelopers.6.2.1Non-optimizationbugsNon-optimizationbugsareunstablecodethatcausesprob-lemsevenwithoutoptimizations,suchasthenullpointerdereferencebugshowninFigure2,whichdirectlyinvokesundenedbehavior.Toillustratethesubtleconsequencesofinvokingunde-nedbehavior,considertheimplementationofthe64-bitsigneddivisionoperatorforSQLinthePostgresdatabase,asshowninFigure10.Thecoderstrejectsthecasewherethedivisoriszero.Since64-bitintegersrangefrom�263to263�1,theonlyoverowcaseis�263=�1,wheretheexpectedquotient263exceedstherangeandtriggersundenedbehavior.ThePostgresdevelopersin-correctlyassumedthatthequotientmustwraparoundto�263inthiscase,asinsomehigher-levellanguages(e.g.,Java),andtriedtocatchitbyexaminingtheoverowedquotientafterthedivision,usingthefollowingcheck:arg2==-1&&arg10&&arg1/arg20.Stackidentiesthischeckasunstablecode:thedivi-sionimpliesthattheoverowmustnotoccurtoavoidundenedbehavior,andthustheoverowcheckafterthedivisionmustbefalse.WhilesigneddivisionoverowisundenedbehaviorinC,thecorrespondingx86-64instructionIDIVtrapsonoverow.Onecanexploitthistocrashthedatabasecharbuf[15];/*filledwithdatafromuserspace*/unsignedlongnode;char*nodep=strchr(buf,'.')+1;if(!nodep)return-EIO;node=simple_strtoul(nodep,NULL,10); Figure11:AnincorrectnullpointercheckintheLinuxsysctlim-plementationfor/proc/sys/net/decnet/node_address.Acorrectnullcheckshouldtesttheresultofstrchr,ratherthanthatplusone,whichisalwaysnon-null.serveronx86-64bysubmittingaSQLquerythatinvokes�263=�1,suchas:SELECT((-9223372036854775808)::int8)/(-1);Interestingly,wenoticethatthePostgresdeveloperstestedthe�263=�1crashin2006,butincorrectlyconcludedthatthis“seemedOK”[34].WebelievethereasonisthattheytestedPostgresonx86-32,wheretherewasno64-bitIDIVinstruction.Inthatcase,thecompilerwouldgenerateacalltoalibraryfunctionlldivfor64-bitsigneddivision,whichreturns�263for�263=�1ratherthanahardwaretrap.Thedevelopershenceoverlookedthecrashissue.Toxthisbug,wesubmittedastraightforwardpatchthatcheckswhetherarg1is�263andarg2is�1beforearg1=arg2.However,thePostgresdevelopersinsistedontheirownx.Particularly,insteadofdirectlycomparingarg1with�263,theychosethefollowingcheck:arg1!=0&&(-arg10)==(arg10).Stackidentiesthischeckasunstablecodeforsimilarreasons:thenegation�arg1impliesthatarg1cannotbe�263toavoidundenedbehavior,andthusthecheckmustbefalse.Wewillfurtheranalyzethischeckin§6.2.3.Byidentifyingunstablecode,Stackisalsousefulforuncoveringprogrammingerrorsthatdonotdirectlyin-vokeundenedbehavior.Figure11showsanincorrectnullpointercheckfromtheLinuxkernel.Theintentionofthischeckwastorejectanetworkaddresswithoutanydots.Sincestrchr(buf,'.')returnsnullifitcannotndanydotsinbuf,acorrectcheckshouldcheckwhetheritsresultisnull,ratherthanthatplusone.Onecanbypassthecheck!nodepwithamalformednetworkaddressfromuserspaceandtriggeraninvalidreadatpagezero.Stackidentiesthecheck!nodepasunstablecode,becauseun-dertheno-pointer-overowassumptionnodep(apointerplusone)mustbenon-null.6.2.2UrgentoptimizationbugsUrgentoptimizationbugsareunstablecodethatexistingcompilersalreadyoptimizetocauseproblems.§2.2de-scribedasetofexampleswherecompilerseitherdiscardtheunstablecodeorrewriteitintosomevulnerableform.Toillustratetheconsequences,considerthecodesnip-petfromFFmpeg/LibavforparsingAdobe'sActionMes-sageFormat,showninFigure12.Theparsingcodestarts10 UBcondition#reports#packages nullpointerdereference59,2302,800bueroverow5,7951,064signedintegeroverow4,364780pointeroverow3,680614oversizedshift594193aliasing33070overlappingmemorycopy22747divisionbyzero22695useafterfree15679otherlibc(cttz,ctlz)1327absolutevalueoverow8623useafterrealloc2210 Figure18:NumberofreportsthatinvolveeachofStack'sUBcon-ditionsfromFigure3forallDebianWheezypackages,andthenumberofpackagesforwhichatleastonesuchreportwasgen-erated.Asdescribedin§4.5,StackcomputesaminimalsetofUBconditionsnecessaryforeachinstanceofunstablecode.Mostunstablecodereports(69,301)weretheresultofjustoneUBcondition,buttherewerealso2,579reportswithmorethanoneUBcondition,andtherewereeven4reportsinvolvingeightUBconditions.Thesenumbersconrmthatsomeunstablecodeiscausedbymultipleundenedbehaviors,whichsuggeststhatautomatictoolssuchasStackarenecessarytoidentifythem.Program-mersareunlikelytondthembymanualinspection.6.6CompletenessStackisabletoidentifyalltheunstablecodeexamplesde-scribedin§2.3.However,itisdiculttoknowpreciselyhowmuchunstablecodeStackwouldmissingeneral.In-steadweanalyzewhatkindofunstablecodeStackmisses.Todoso,wecollectedallexamplesfromRegehr's“un-denedbehaviorconsequencescontest”winners[40]andWangetal.'sundenedbehaviorsurvey[49]asabench-mark,atotaloftentestsfromrealsystems.Stackidentiedunstablecodeinsevenoutofthetentests.Stackmissedthreeforthefollowingreasons.Asdescribedin§4.6,StackmissedtwobecausewechosenottoimplementtheirUBconditionsforviolationsofstrictaliasingandusesofuninitializedvariables;itwouldbeeasytoextendStacktodoso.TheothercaseStackmissedwasduetoapproximatereachabilityconditions,alsomentionedin§4.6.7RelatedworkTothebestofourknowledge,wepresenttherstdeni-tionandstaticcheckertondunstablecode,butwebuildonseveralpiecesofrelatedwork.Inparticular,earliersurveys[26,41,49]andblogposts[29,39,40]collectexamplesofunstablecode,whichmotivatedustotacklethisproblem.Wewerealsomotivatedbyrelatedtech-niquesthatcanhelpwithaddressingunstablecode,whichwediscussnext.Testingstrategies.Ourexperiencewithunstablecodeshowsthatinpracticeitisdicultforprogrammerstonoticecertaincriticalcodefragmentsdisappearingfromtherunningsystemastheyaresilentlydiscardedbythecompiler.Maintainingacomprehensivetestsuitemayhelpcatch“vanished”codeinsuchcases,thoughdoingsooftenrequiresasubstantialeorttoachievehighcodecoveragethroughmanualtestcases.Programmersmayalsoneedtoprepareavarietyoftestingenvironmentsasunstablecodecanbehardware-andcompiler-dependent.AutomatedtoolssuchasKLEE[4]cangeneratetestcaseswithhighcoverageusingsymbolicexecution.Thesetools,however,oftenfailtomodelundenedbehaviorcorrectly.Thus,theymayinterprettheprogramdierentlyfromthelanguagestandardandmissbugs.Consideracheckx+100x,wherexisasignedinteger.KLEEconsidersx+100towraparoundgivenalargex;inotherwords,thecheckcatchesalargexwhenexecutinginKLEE,eventhoughgccdiscardsthecheck.Therefore,todetectunstablecode,thesetoolsneedtobeaugmentedwithamodelofundenedbehavior,suchastheoneweproposedinthispaper.Optimizationstrategies.Webelievethatprogrammersshouldavoidundenedbehavior,andweprovidesugges-tionsforxingunstablecodein§6.2.However,overlyaggressivecompileroptimizationsarealsoresponsiblefortriggeringthesebugs.Traditionally,compilersfocusedonproducingfastandsmallcode,evenatthepriceofsacri-cingsecurity,asshownin§2.2.Compilerwritersshouldrethinkoptimizationstrategiesforgeneratingsecurecode.Considerx+100xwithasignedintegerxagain.Thelanguagestandarddoesallowcompilerstoconsiderthechecktobefalseanddiscardit.Inourexperience,however,itisunlikelythattheprogrammerintendedthecodetoberemoved.Aprogrammer-friendlycompilercouldinsteadgenerateecientoverowcheckingcode,forexample,byexploitingtheoverowagavailableonmanyprocessorsafterevaluatingx+100.Thisstrategy,alsoallowedbythelanguagestandard,producesmoresecurecodethandiscardingthecheck.Alternatively,thecompilercouldproducewarningswhenexploitingundenedbehaviorinapotentiallysurprisingway[19].Currently,gccprovidesseveraloptionstoalterthecom-piler'sassumptionsaboutundenedbehavior,suchas-fwrapv,assumingsignedintegerwraparoundforad-dition,subtraction,andmultiplication;-fno-strict-overflow,assumingpointerarithmeticwraparoundinadditionto-fwrapv;and-fno-delete-null-pointer-checks[44],assumingunsafenullpointerdereferences.13 [2]H.-J.Boehm.Threadscannotbeimplementedasalibrary.InProceedingsofthe2005ACMSIGPLANConferenceonProgrammingLanguageDesignandImplementation(PLDI),pages261–268,Chicago,IL,June2005.[3]R.BrummayerandA.Biere.Boolector:AnecientSMTsolverforbit-vectorsandarrays.InProceed-ingsofthe15thInternationalConferenceonToolsandAlgorithmsfortheConstructionandAnalysisofSystems,pages174–177,York,UK,Mar.2009.[4]C.Cadar,D.Dunbar,andD.Engler.KLEE:Unas-sistedandautomaticgenerationofhigh-coveragetestsforcomplexsystemsprograms.InProceedingsofthe8thSymposiumonOperatingSystemsDesignandImplementation(OSDI),SanDiego,CA,Dec.2008.[5]G.Canet,P.Cuoq,andB.Monate.AvalueanalysisforCprograms.InProceedingsofthe9thIEEEInternationalWorkingConferenceonSourceCodeAnalysisandManipulation,pages123–124,Edmon-ton,Canada,Sept.2009.[6]H.Chen,Y.Mao,X.Wang,D.Zhou,N.Zeldovich,andM.F.Kaashoek.Linuxkernelvulnerabilities:State-of-the-artdefensesandopenproblems.InProceedingsofthe2ndAsia-PacicWorkshoponSystems,Shanghai,China,July2011.[7]Chromium.Issue12079010:Avoidundenedbehaviorwhencheckingforpointerwraparound,2013.https://codereview.chromium.org/12079010/.[8]A.Cimatti,A.Griggio,andR.Sebastiani.Comput-ingsmallunsatisablecoresinsatisabilitymodulotheories.JournalofArticialIntelligenceResearch,40:701–728,2011.[9]Clang.ClangCompilerUser'sMan-ual:ControllingCodeGeneration,2013.http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation.[10]J.Corbet.FunwithNULLpointers,part1,July2009.http://lwn.net/Articles/342330/.[11]W.Dietz,P.Li,J.Regehr,andV.Adve.Understand-ingintegeroverowinC/C++.InProceedingsofthe34thInternationalConferenceonSoftwareEn-gineering(ICSE),pages760–770,Zurich,Switzer-land,June2012.[12]I.Dillig,T.Dillig,andA.Aiken.Staticerrorde-tectionusingsemanticinconsistencyinference.InProceedingsofthe2007ACMSIGPLANConferenceonProgrammingLanguageDesignandImplemen-tation(PLDI),pages435–445,SanDiego,CA,June2007.[13]C.R.DoughertyandR.C.Seacord.Ccompil-ersmaysilentlydiscardsomewraparoundchecks.VulnerabilityNoteVU#162289,US-CERT,2008.http://www.kb.cert.org/vuls/id/162289.[14]C.EllisonandG.Ro¸su.Anexecutableformalse-manticsofCwithapplications.InProceedingsofthe39thACMSymposiumonPrinciplesofProgram-mingLanguages(POPL),pages533–544,Philadel-phia,PA,Jan.2012.[15]C.EllisonandG.Ro¸su.DeningtheundenednessofC.Technicalreport,UniversityofIllinois,Apr.2012.http://hdl.handle.net/2142/30780.[16]D.Engler,D.Y.Chen,S.Hallem,A.Chou,andB.Chelf.Bugsasdeviantbehavior:Ageneralap-proachtoinferringerrorsinsystemscode.InPro-ceedingsofthe18thACMSymposiumonOperatingSystemsPrinciples(SOSP),pages57–72,ChateauLakeLouise,Ban,Canada,Oct.2001.[17]GCC.Bug30475-assert(int+100−int)op-timizedaway,2007.http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475.[18]GCC.Bug49820-explicitcheckforintegernega-tiveafterabsoptimizedaway,2011.http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49820.[19]GCC.Bug53265-warnwhenundenedbehaviorimpliessmalleriterationcount,2013.http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53265.[20]D.Gohman.Thenswstory,Nov.2011.http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-November/045730.html.[21]IBM.PowerISAVersion2.06RevisionB,BookI:PowerISAUserInstructionSetArchitecture,July2010.[22]Intel.Intel64andIA-32ArchitecturesSoftwareDeveloper'sManual,Volume2:InstructionSetRef-erence,A–Z,Jan.2013.[23]ISO/IECJTC1/SC22/WG14.RationaleforInterna-tionalStandard-ProgrammingLanguages-C,Apr.2003.[24]ISO/IECJTC1/SC22/WG14.ISO/IEC9899:2011,Programminglanguages-C,Dec.2011.[25]B.Jack.Vectorrewriteattack:ExploitableNULLpointervulnerabilitiesonARMandXScalearchi-tectures.Whitepaper,JuniperNetworks,May2007.[26]R.KrebbersandF.Wiedijk.SubtletiesoftheANSI/ISOCstandard.DocumentN1639,ISO/IECJTC1/SC22/WG14,Sept.2012.[27]T.Lane.Anyoneforadding-fwrapvtoourstandardCFLAGS?,Dec.2005.http://www.postgresql.org/message-id/1689.1134422394@sss.pgh.pa.us.15 [28]T.Lane.Re:gccversusdivision-by-zerotraps,Sept.2009.http://www.postgresql.org/message-id/19979.1251998812@sss.pgh.pa.us.[29]C.Lattner.WhateveryCprogrammershouldknowaboutundenedbehavior,May2011.http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html.[30]C.LattnerandV.Adve.LLVM:Acompilationframeworkforlifelongprogramanalysis&trans-formation.InProceedingsofthe2004Interna-tionalSymposiumonCodeGenerationandOpti-mization(CGO),pages75–86,PaloAlto,CA,Mar.2004.[31]Linuxkernel.Bug14287-ext4:xpointdivideexceptionatext4_fill_super,2009.https://bugzilla.kernel.org/show_bug.cgi?id=14287.[32]D.MacKenzie,B.Elliston,andA.Demaille.Auto-conf:CreatingAutomaticCongurationScriptsforversion2.69.FreeSoftwareFoundation,Apr.2012.[33]W.M.Miller.C++standardcorelanguagedefectreportsandacceptedissues,issue1457:Undenedbehaviorinleft-shift,Feb.2012.http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1457.[34]B.Momjian.Re:FixforWin32divisionin-volvingINT_MIN,June2006.http://www.postgresql.org/message-id/200606090240.k592eUj23952@candle.pha.pa.us.[35]S.S.Muchnick.AdvancedCompilerDesignandImplementation.MorganKaufmann,1997.[36]D.Novillo.ApropagationengineforGCC.InPro-ceedingsofthe2005GCC&GNUToolchainDe-velopers'Summit,pages175–184,Ottawa,Canada,June2005.[37]Python.Issue17016:_sre:avoidrelyingonpointeroverow,2013.http://bugs.python.org/issue17016.[38]S.Ranise,C.Tinelli,andC.Barrett.QF_BVlogic,2013.http://smtlib.cs.uiowa.edu/logics/QF_BV.smt2.[39]J.Regehr.AguidetoundenedbehaviorinCandC++,July2010.http://blog.regehr.org/archives/213.[40]J.Regehr.Undenedbehaviorconsequencescontestwinners,July2012.http://blog.regehr.org/archives/767.[41]R.C.Seacord.Dangerousoptimiza-tionsandthelossofcausality,Feb.2010.https://www.securecoding.cert.org/confluence/download/attachments/40402999/Dangerous+Optimizations.pdf.[42]R.M.StallmanandtheGCCDeveloperCommunity.UsingtheGNUCompilerCollectionforGCC4.8.0.FreeSoftwareFoundation,2013.[43]M.Stephenson,J.Babb,andS.Amarasinghe.Bitwidthanalysiswithapplicationtosiliconcompi-lation.InProceedingsofthe2000ACMSIGPLANConferenceonProgrammingLanguageDesignandImplementation(PLDI),pages108–120,Vancouver,Canada,June2000.[44]E.Teo.[PATCH]add-fno-delete-null-pointer-checkstogccCFLAGS,July2009.https://lists.ubuntu.com/archives/kernel-team/2009-July/006609.html.[45]J.Tinnes.BypassingLinuxNULLpointerdereferenceexploitprevention(mmap_min_addr),June2009.http://blog.cr0.org/2009/06/bypassing-linux-null-pointer.html.[46]L.Torvalds.Re:[patch]CFSscheduler,-v8,May2007.https://lkml.org/lkml/2007/5/7/213.[47]J.Tourrilhes.Invalidcompilationwithout-fno-strict-aliasing,Feb.2003.https://lkml.org/lkml/2003/2/25/270.[48]P.TuandD.Padua.GatedSSA-baseddemand-drivensymbolicanalysisforparallelizingcompilers.InProceedingsofthe9thACMInternationalConfer-enceonSupercomputing,pages414–423,Barcelona,Spain,July1995.[49]X.Wang,H.Chen,A.Cheung,Z.Jia,N.Zeldovich,andM.F.Kaashoek.Undenedbehavior:Whathappenedtomycode?InProceedingsofthe3rdAsia-PacicWorkshoponSystems,Seoul,SouthKorea,July2012.[50]X.Wang,H.Chen,Z.Jia,N.Zeldovich,andM.F.Kaashoek.ImprovingintegersecurityforsystemswithKint.InProceedingsofthe10thSympo-siumonOperatingSystemsDesignandImplementa-tion(OSDI),pages163–177,Hollywood,CA,Oct.2012.[51]K.WinsteinandH.Balakrishnan.Mosh:Aninterac-tiveremoteshellformobileclients.InProceedingsofthe2012USENIXAnnualTechnicalConference,pages177–182,Boston,MA,June2012.[52]N.Zeldovich,S.Boyd-Wickizer,E.Kohler,andD.Mazières.MakinginformationowexplicitinHiStar.InProceedingsofthe7thSymposiumonOp-eratingSystemsDesignandImplementation(OSDI),pages263–278,Seattle,WA,Nov.2006.16