/
Runtime Defenses Nicholas Carlini  September   Baggy Bounds Checking Runtime Defenses Nicholas Carlini  September   Baggy Bounds Checking

Runtime Defenses Nicholas Carlini September Baggy Bounds Checking - PDF document

briana-ranney
briana-ranney . @briana-ranney
Follow
465 views
Uploaded On 2015-02-21

Runtime Defenses Nicholas Carlini September Baggy Bounds Checking - PPT Presentation

1 Motivation There are large amounts of legacy C programs which can not be rewritten entirely Since memory must be manually managed in C and bounds are not checked automatically on pointer dereferences C often contains many memorysaftey bugs One comm ID: 37470

Motivation There are large

Share:

Link:

Embed:

Download Presentation from below link

Download Pdf The PPT/PDF document "Runtime Defenses Nicholas Carlini Septe..." 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

AssumetheCprogramcontainsanover owintheusernamebu erofthestruct.Sincebaggyboundscheckingwillonlydetectproblemswhenapointerisdereferencedinadi erentallocatedobject,theusernamebu ercouldstillbeover owedtooverwriteeithertheauthenticated agorthefunctionpointer.Thisgivesnobene tovertypicaluninstrumentedcode.Onedisadvantageofthisisitmeansthatanyprogramwhichwritesit'sownallocatorinordertotakeadvantageofspeci cprogram-speci cproperties(whichmaymaketheallocatorabletodoabetterjobthanthenormalmalloc)willnotbeabletomakeuseofbaggyboundschecking.1.4ComparisonwithJavaItwouldbegoodtoknowhowthespeedofaninstrumentedCprogramcomparedtoaJavaprogramintermsofspeed:iftheJavaprogramwasjustasfast,thenitwouldbemuchsafertojustuseJavafornewprojects.However,forlegacyprograms,itisnotalwayspossibletorewritetheentireprojectinJava,evenifitturnsoutthatJavawasjustasfast.1.5CompileTimeBoundsCheckingThisbringsrisetoaquestion:whydoesn'tCdowhatJavadoesandputcompile-timecheckboundsonthebu ers?Thisworksinsomecases,andrelatedworkhasdonethingslikethiswhenthesizeofthebu erisknownstatically.However,arrayscanbecreateddynamicallywherethecompilerwillnotknowthebounds.Forexample,considerthelineofC: charx=p��buf[i]; Thiscasecanbecheckedstaticallybyinsertingtheboundscheck,assumingtheprogramknowsthatpisoftypestructUser*. if(i�=0&&i128)f exit(1);//Ohno! g charx=p��buf[i]; However,themoredicultcaseiswhenafunctiontakesavoid*pointerasanargument,withnoideawhopassedthepointerorwhatinformationthereisaboutthepointer.Inordertosolvethis,wewouldneedaboundstabletolookupthisinformation.1.5.1UninstrumentedCodeItisoftenthecaseinlargeprogramsthatnotallofthesourcecodeisavailable.Itmaybethatabinaryexistsforalibrary,butthereisnosourcecodetorecompilethatbinaryunderthenewcompiler.Inthiscase,thispre-existingsourcecodeiscalled\uninstrumentedcode". 1.7.1IssuesDespitetheadvantages,therearemanyissueswithfatpointers.OneofthemajorissuesisthatmostCprogramsassumepointersona32bitsystemwillbeonlyfourbytes|aprogrammermaywritemalloc(4*n)insteadofmalloc(sizeof(void*)*n),andinthiscase,afatpointerwillnothavespacetobeplaced.Theproblemsbecausemuchmoredicultwhendealingwithuninstrumentedlibraries.Theselibrarieswillexpectonlypointers,andnotthefatpointers.Itisnottoodiculttomodifypointerswhenpassingthemassingleargumentstofunctionsinuninstrumentedlibraries:insteadofpassingthefatpointer,onlythepointerportioncanbepassed.Thisdoesmeanthatuninstrumentedcodewillbene tfromthefatpointers,butitwillatleastworkcorrectly.Whilethepreviouscasewaspossible,itissigni cantlymorediculttodealwithstructsofpoint-ers.Whenpassingastruct,whichmaycontainspointers,betweeninstrumentedcodeandunin-strumentedcode,theuninstrumentedcodewouldnotknowaboutthefatpointers.Oneoptiontosolvethiswouldbetomaintainseparateobjects|onewithfatpointers,andonewithnormalpointers|andre ectallchangesonthefatpointersobjectintheotherandviceversa.However,thisleadstotheproblemthatifoneprogrampassestheaddressofoneofthememorylocationstotheuninstrumentedcode,itwillseethisastheaddressofthefatpointerstructureandnotitscopyofthestructure.Ingeneral,thisisnotaneasyproblemtosolve.Thisisthedrivingcauseofboundstables:boundstablesallowprogramstoworkreasonablywellwithuninstrumentedcode,whilefatpointersdonot.1.8UseinPracticeDespiteallthisworkthatleadtobaggyboundschecking,itisalmostneverusedinpractice,andthisisduetomanyreasons.Cprogramsaredesignedforspeed.AddingbaggyboundscheckingslowsdownCprogramsbydi erentamounts:whilesomeslowdownonly8%othersslowdownbyafactoroftwo.Baggyboundscheckingrestrictsmemoryavailable.Pointersaremadeinvalidbymakinghalfoftheaddressspacebeinvalid,andafurtherblockisusedfortheboundstable.Programsmustberecompiledwithanewmemoryallocator.Anyfragilecodewhichhappenstoworkusingthedefaultmemoryallocatormaynotworkwithadi erentallocator.BaggyboundscheckingcompetesagainstASLR+DEP.Thesetwodefensesprovideagoodenoughsecurityassurance,anddonotslowprogramexecution. 2.2ModernCommandInjectionModerncommandinjectionisverysimilartothepreviouslydescribedexamples.Considerthefollowingprogram: system("/usr/bin/mail "+addr); Iftheaddrvariableisnotcheckedforinvalidcharacters,thenanaddressof"foo;halt;"willcausethecomputertobeshutdown(assumingtheuserhasthepermissiontodoso).Anotherexamplewouldbethefollowingstatement: Stringstatement="SELECT  FROM users WHERE user="+username; AuserwhocouldmakehisnameJohnOR1==1couldmaketheSELECTstatementshowalistofallusers.Evenworse,however,istheusercouldmakehisnameJohn;DROPTABLEusers;.Thisisoccasionally\ xed"byplacingquotesaroundtheusername: Stringstatement="SELECT  FROM users WHERE user='"+username+"'"; HoweverthiscanbedefeatedbymakinganameofJohn';DROPTABLEusers;--,sincethesinglequotewillendthequotedtextandthe--willcausetherestofthelinetobeacomment.2.3TaintTaintanalysistrackswhereinputcomesfrom.Ifinputcomesfromtheuser,wetreatitasuntrusted.Iftheinputcomesfromtheprogram(e.g.,asastaticstringorasdatafromatrustedserver)thenitistreatedastrusted.Thepaperhasadetaileddiscussionofhowtaintshould owfromplacetoplaceinanecientmanner.2.4PoliciesTaintbyitselfhasverylittleuse.Wherethetaintbecomesusefulisincreatingpolicieswhichgovernwhatsourcesareallowedto owtospeci csinks.Thispaperdoesnotspendmuchtimediscussingpolicies,eventhoughpoliciesareoneofthecriticalaspectsofusingtaint.TheonepolicytheygiveasanexampleisforSQL.SQLinjection,asdescribedearlier,isaverycommonproblemondatabases.Itispossibletousetainttotrytosolvethisissue.Thespeci cpolicythatthepaperproposedwastocheckSQLcommandsfor(OR)tj(SELECT)tj(FROM)tj:::wherextmeansthatxtainted.Thatis,thispolicycheckstoseeifaSQLquerycontainsanyofthosewordsintaintedlocations,andifso,thenassumethatthequeryisdangerous.