columbiaedu Columbia University Sotiris Ioannidis sicsstevensedu Stevens Institute of Technology Angelos D Keromytis angeloscscolumbiaedu Columbia University Abstract Testing vendorissued patches remains one of the major hurdles to their speedy deplo ID: 47345
Download Pdf The PPT/PDF document "Bandaid Patching Stelios Sidiroglou stel..." 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.
oftheapplication.Generally,securityandstabilitypatchesfallinthiscategory.Althoughourschemecouldbeap-pliedagainstanytypeofpatch(e.g.,largepatchesintroduc-ingnewfunctionality),thecostandcomplexityassociatedwouldlikelybetoohigh.Asapreliminaryvalidatationofourapproach,wede-velopedaproof-of-conceptimplementationofBand-aidPatchingusingsource-to-sourcetransformationsandthedyninst[ 3 ]runtimeinstrumentationtool.Specically,weusedyninsttoinsertinstrumentationtrampolinesthatpointtothedi erentversionsofthepatchesundertest,andinstru-mentationthatexaminesandcomparestheoutputofthesepatches.Thetypeofpatchesthatcanbeappliedcanrangefromsimplelogicbugxestotestingnewvulnerabilitypro-tectionmechanisms.Formorecomplexupdates,i.e.,wherechangestofunctionprototypesandtypedenitionsarere-quired,ourapproachcouldbecombinedwithmoresophis-ticateddynamicsoftwareupdatetechniques[ 5 , 10 ].Otherpromisingrecentworkinthisspace[ 6 ]usesvirtualma-chinescombinedwithvulnerability-specicpredicatesthatareexecutedinthecontextofthevulnerableprocesstotestwhetheraawisbeingexercised(orwasexercisedatsomepointinthepast,ifsuchlogsareavailable).However,thesepredicatesmustbegeneratedmanually,andrequireintimateknowledgeoftheapplicationandthepatch(orthevulner-ability).Incontrast,ourtechniqueusesonlythevendor-issuedpatchandcanbeappliedwithlittleornointerven-tionbyusersoradministrators.Inthispreliminarywork,weexposesomeoftheissuesassociatedwithourapproachandidentifyareasforfutureinvestigation.2ApproachConceptually,ourapproachcanbedescribedbytwocomponents:anexecutionmoduleandadecisionmodule.Theexecutionmoduleprovidesthespeculativeexecu-tionenvironmentwherepatchescanbeappliedtoserviceinstances.Itispossiblethatmultiplesuchinstancesruninparallelwhilebeingmonitoredbytheexecutionenviron-mentforsuccessfulterminationorforexceptionfailures.Themoduleprovidesarecoverymechanismtomaintainnon-stopserviceexecutioninthepresenceoffaults.Thedecisionmoduleconsistsofasetofdetectionele-mentsthatexaminetheoutput(statechanges)generatedbyindividualexecutions,processtheresults,andreachadeci-sion.Themodulemustbeinvokedwheneverparallelrun-ninginstancesofservicesreachpredenedpointsintheirexecution,orwhenanexceptionisgenerated.Intheremainderofthissection,weoutlinethefunctionalrequirementsforthesetwomodules. 2.1ExecutionModuleTheexecutionmoduledesignatesthemechanismfortheapplicationofpatchestoserviceinstances.Ideally,thepatchingmechanismshouldbeableto:(i)applypatchestorunningserviceinstanceswithlittleornodown-time,(ii)allowfortheapplicationofarbitrarypatches(i.e.,notjustbinary-compatible),(iii)havetheabilitytoapplypatchesevenintheabsenceofsourcecode,(iv)providetheabilitytoinsertmultiplepatchesatspecicprogramlocations,and(v)monitormultiplespeculativeexecutionsforsuccessfulcompletionorfaults.Thereareafewinstrumentationinjectiontechniquesthatcanbeemployedforthepurposesofourapproach. Binarytranslation,wherethetooladdsinstrumentationtoacompiledbinary,e.g.,ATOM[ 15 ] Runtimeinstrumentation,wherethecodeisinstru-mentedjustpriortoexecution,e.g.,PIN[ 7 ] Runtimeinjection.Thisisamorelight-weightap-proachthanruntimeinstrumentation,wherethecodeismodiedatruntimebyinsertingjumpstohelperfunc-tions,e.g.,dyninst[ 3 ]Runtimeinstrumentationprovidesthemostexibleplat-form,atthecostofhigherperformanceoverhead.Forex-amplePIN[ 7 ],aruntimeinjectiontool,usesadynamictranslationtointerceptandmakechangestoruntimecode,whichtypicallyaddsa2xoverhead.Dyninst[ 3 ]usesarun-timeinjectionapproachthataddsminimaloverheadtotheapplicationbutrequiresthatpatchesmaintainbinarycom-patibility.Theissueofbinarycompatibilityisofminorimportancegiventhefactthatthemajorityofvulnerabil-itypatchesusuallyinvolveminimalchangestotheunder-lyingsourcecode.Infact,inordertoprovideanysortoftype-safetyondynamicsoftwareupdating,onewouldhavetousealanguagethatisdynamic-updateaware[ 16 ].Theoverheadofexecutingtheinsertedinstrumentationiscom-parabletothatofafunctioncallandprimarilydependsonhowecientlyregisterscanbesavedandrestoredduringexecution.Numerousapproachesonsupportingdynamicsoftwareupdating(DSU)havebeenproposedintheliterature[ 5 , 2 , 10 ].Themostexible,intermsofthekindofupdatesthataresupported,arepopcorn[ 5 ]andginseng[ 10 ].Bothofthesesystemsuseacompiler-basedapproachtoensuretype-safetyanddataintegrityforsoftwareupdates.Ingin-seng,source-to-sourcetransformationsareusedtohandlethetransformationofdatawhosetypechangesasaresultoftheupdateandtoallowforthedynamicupdateofinniteloops.Unfortunately,thecostofupdateexibilityisper-formance.Ginsengexhibitsaperformanceoverheadthatis 2 useruntimeinjectionforpatchinsertion.Weusedyninst[ 3 ]duetoitslowruntimeoverheadanditsabilitytoattachanddetachfromalreadyrunningprocesses.Theupdatessupportedbyourprototypehappenatfunction-levelgranularity,andcomeintoe ectonthenextinvocationofthereplacedfunction.Thedi erentversionsofthepatchestobetestedarecreatedasadynamiclibrarythatcanbelinkedtotheapplicationatruntime.Thefunc-tionwheretheBand-aidPatchingwillbeinitiatedinisin-strumentedtoincludecallstothepatchestobetestedonfunctionentry.Unfortunately,theobviouschoiceof“forking”adi er-entprocessforeachexecutionthreatcarriesthestigmaasso-ciatedwithchangingprocessinformation;toavoidbreakingprogramsemantics,specialcareneedstobeplacedonpro-gramsthatrelyonprocessIDinformation.Usingdyninst,wecaninterceptcallstogetpidanditsderivativestore-turntheappropriateprocessID.However,thissolutionisnopanaceaastheprocessIDmighthavebeencommuni-catedtootherpartsoftheapplicationpriortothepatchde-ployment.ApossiblesolutionistoaddathinvirtualizationlayerthatmapsallprocessIDstovirtualvalues[ 11 ].Analternativeapproachwouldbetoexecutethedi erentver-sionsofapatchinsuccession.Whilethisapproachisele-gantinitssimplicity,itmeansthatwecanonlyexplorethee ectsofapatchwithintheconnesofthefunction,i.e.,wewouldnotbeabletoexaminepossibleside-e ectsexhibitedbyapatchfartherdowninprogramexecution.Wealsocan-nottakeadvantageofhardwarefacilities,suchasmultipleprocessors/cores,thatcouldminimizetheoverheadofourscheme.Forthisparticularimplementationweemploythesequentialpatchapproachusingatoolwehavepreviouslydeveloped,STEM[ 13 ].Thedecisioncomponentiscur-rentlyimplementedasanapplication-speciccomponentthatcanbeinjectedatparticularprogramlocationsusingthemechanismdescribedpreviously.Forourprototype,weuseSTEMtodetectgeneralfaultsandmemoryviolations.Ifapatchdoesnotintroduceafailureduringexecution,ex-ecutionisallowedtocontinue.Ifthepatchcausesafail-ure,executioncontinueswiththeun-patchedversionofthecode.4ConclusionsWehaveproposedanewapproachfordynamicallytest-ingmultiplepatchesonlong-runningserviceinstances.Togainsomeinsightintotheissuesassociatedwithourap-proach,wehavedevelopedaprototypeimplementation.Thisproof-of-conceptsystemhasaddressedandidentiedasetofpracticalissuespertainingtothisnewapproach.How-ever,wefeelthatthissetofissuesrepresentsonlythetipoftheiceberg.Furtherresearchwillneedtofocusonthese pressingissueslikegamingattacks,semanticcorrectnessandecientstatecomparisons.References [1] M.Abadi,M.Budiu,U.Erlingsson,andJ.Ligatti.Control-owintegrity.InProceedingsofthe12thACMconferenceonComputerandCommunicationsSecurity(CCS),pages340–353,2005. [2] G.Altekar,I.Bagrak,P.Burstein,andA.Schultz.OPUS:OnlinePatchesandUpdatesforSecurity.InProceedingsofthe14thUSENIXSecuritySymposium,August2005. [3] B.BuckandJ.K.Hollingsworth.AnAPIforruntimecodepatching.TheInternationalJournalofHighPerformanceComputingApplica-tions,14(4):317–329,Winter2000. [4] C.Cowan,H.Hinton,C.Pu,andJ.Walpole.TheCrackerPatchChoice:AnAnalysisofPostHocSecurityTechniques.InPro-ceedingsoftheNationalInformationSystemsSecurityConference(NISSC),October2000. [5] M.W.Hicks,J.T.Moore,andS.Nettles.DynamicSoftwareUp-dating.InSIGPLANConferenceonProgrammingLanguageDesignandImplementation,pages13–23,June2001. [6] A.Joshi,S.T.King,G.W.Dunlap,andP.M.Chen.DetectingPastandPresentIntrusionsthroughVulnerability-SpecicPredicates.InProceedingoftheACMSymposiumonOperatingSystemsPrinciples(SOSP),October2006. [7] C.-K.Luk,R.Cohn,R.Muth,H.Patil,A.Klauser,G.Lowney,S.Wallace,V.J.Reddi,andK.Hazelwood.Pin:Buildingcustomizedprogramanalysistoolswithdynamicinstrumentation.InProgram-mingLanguageDesignandImplementation,pages190–200,June2005. [8] E.MarcusandH.Stern.Blueprintsforhighavailability:designingresilientdistributedsystems.JohnWiley&Sons,Inc.,2000. [9] K.Muniswamy-Reddy,C.P.Wright,A.Himmer,andE.Zadok.AVersatileandUser-OrientedVersioningFileSystem.InProceed-ingsofthe3rdUSENIXConferenceonFileandStorageTechnologies(FAST),pages115–128,March/April2004. [10] I.Neamtiu,M.Hicks,G.Stoyle,andM.Oriol.Practicaldynamicsoftwareupdatingforc.InProceedingsoftheACMSIGPLANconferenceonProgramminglanguagedesignandimplementation(PLDI),pages72–83,2006. [11] S.Osman,D.Subhraveti,G.Su,andJ.Nieh.Thedesignandimple-mentationofZap:Asystemformigratingcomputingenvironments.InProceedingsofthe5thUSENIXSymposiumonOperatingSys-temsDesignandImplementation(OSDI),pages361–376,December2002. [12] E.Rescorla.Securityholes...Whocares?InProceedingsofthe12thUSENIXSecurityConference,August2003. [13] S.Sidiroglou,M.E.Locasto,S.W.Boyd,andA.D.Keromytis.BuildingaReactiveImmuneSystemforSoftwareServices.InPro-ceedingsoftheUSENIXTechnicalConference,pages149–161,April2005. [14] A.SomayajiandS.Forrest.AutomatedresponseusingSystem-Calldelays.InProceedingsofthe9thUSENIXSecuritySymposium,pages185–198,August2000. [15] A.SrivastavaandA.Eustace.Atom:asystemforbuildingcus-tomizedprogramanalysistools.InProceedingsoftheACMSIG-PLANConferenceonProgrammingLanguageDesignandImple-mentation(PLDI),pages196–205,June1994. 4 [16] G.Stoyle,M.Hicks,G.Bierman,P.Sewell,andI.Neamtiu.Mutatismutandis:safeandpredictabledynamicsoftwareupdating.InPro-ceedingsofthe32ndACMSIGPLAN-SIGACTsymposiumonPrinci-plesofProgrammingLanguages(POPL),pages183–194,2005. 5