SecurityMitigationsforROPAttacks

1、security mitigations for return-oriented programming attackspiotr baniakryptoslogic r2010abstractwiththe discovery of new exploittechniques, newprotectionmechanismsare needed as well.mit-igationslikedep(dataexecutionprevention)or aslr(addressspace layoutrandomization)createda signi?cantlymore di?cul

2、tenvironmentfor vulnerabilityexploitation.attackers,however,have recentlydeveloped new exploitationmethodswhichare capable of bypassing the operatingsys-tems securityprotectionmechanisms.inthispaperwe presenta shortsummaryofnovelandknownmitigationtechniquesagainstreturn-orientedprogramming(rop)attac

3、ks.thetechniquesdescribedinthisarticlearerelatedmostlyto x86-321processors and microsoftwin-dows operatingsystems.1introductioninorderto increase the securitylevel of the op-eratingsystem, microsofthas implementedseveralmitigationmechanisms,such as depand aslr.data executionprevention(dep)is a secur

4、ity fea-turethat prohibitsthe applicationfrom executingcode fromnon-executablememoryarea.to ex-ploita vulnerability,an attackermust?nd a ex-ecutablememoryregion and be able to ?ll it withnecessary data (e.g., shellcode instructions).gen-erally,achievingthisgoal usingoldexploitationtechniquesis made

5、signi?cantlymore di?cultwiththe additionof the depmechanism.as a result,attackersimproveduponthe classic “return-into-1some of the techniquescan be also appliedon otherar-chitectures,albeitsome of themare onlyavailablefor x86-32family(e.g., the ones based on creatingnew segmentdescrip-tors).libc ” t

6、echniqueand startedusing return-orientedprogramming(rop)3, 7 to bypass data execu-tion prevention.techniques like ropare stillbased on the at-tackerunderstandingmemorylayoutcharacteris-tics, leading microsoftto implementaddress spacelayoutrandomization(aslr)as a countermea-sure. aslrrenders the layo

7、utof an applicationsaddress space less predictablebecause it relocatesthe base addresses of executable modules and othermemory mappings.in order to bypass dep protec-tion mechanism rop technique was introduced.inthis article we present novel and known mechanismswhichare created speci?callyto prevent

8、attackersfrom exploitingvulnerabilitiesbased on the ropmethod.presented mitigationswillbe dividedintwo general categories:? compiler-levelmitigations mitigationsthatcan be only applied by the compileror linker.? binary-levelmitigations mitigationsthatcan be appliedwithoutknowingthesourcecode of the

9、protectedcode fragment.2return-orientedprogram-mingreturn-orientedprogrammingis a known exploita-tiontechniquewhichallowstheattackertousestackmemorytoindirectlyexecutepreviouslypicked instructions(so called gadgets).typicallyeach gadget ends withthe x86 subroutinereturninstruction2(ret ), which furt

10、hertransfersthe ex-ecutiontothe nextgadget or the payloaditself.2howeverotherinstructionsmay be used as well like jmpreg , callregetc.1for more informationregarding the return-orientedprogrammingtechniqueplease refer to 1, 3, 7.3compiler-levelmitigationsin this section we present rop protectionmecha

11、-nisms whichcan be appliedat the compiler-level.howeverthisdoesnt mean theyare notimple-mentable at the binary-level- they are simply sub-stantiallyeasier to implementat the compiler-level.we willalso tryto underlineadvantages and dis-advantages of described mechanisms.the biggest disadvantageof com

12、piler-levelmiti-gations is the fact thatthey requirecode recompi-lationin order to be e?ective.it is often hard toquicklyimplementsuch kind of changes in the realworld.3.1call-retrelationsaspreviouslystated,mostgadgetsuse returninstructionstotransferexecutioncontroltoan-othergadget or payload.inorde

13、rto ?ndusefulgadgets, attackers scan the process memoryor thebinarymodule for returninstructionopcodes and,aftersuch opcode is found,theytrytoperformbackwarddisassemblyin order to decide whetherfollowinggadget is useful (correct)or not.returninstructionopcodescanoftenbefoundinthemiddleofdi?erentinst

14、ructions.results,how-ever, show thatmostof the timeoriginalreturninstructionsret are used.typicallytheyalsorepresentthehighestnumberof returnopcodesfoundintheentiremodulesexecutablearea(cf.figure1).for theremainderof thisarticleret instructionsemittedin the originalprogram scode will be named as “or

15、iginal returninstruction”.3.1.1testingfor callsin typicalapplications,every procedure(function)is executed by using call-procedureinstruction.ev-ery call instructionsaves procedurelinkinginfor-mationon the stack and branches to the procedurespeci?ed by thedestinationoperand.ourropmitigationtechnique

16、relies on a fact thateach re-turnaddress popped from the stack by the retin-structionis preceded by call instruction.whenfigure1:ret opcode o?sets in sample modules(o?set equal to 1 indicatesthatthis is an originalret instruction).2a rop attackoccurs the returnaddress points toanother gadget (or ?na

17、llya payload).it is unlikelythatan attackerwill be able to pick the returnad-dresses preceded by call instructionoperands (seetable 1 for details).testingfor call instructionslocated before the returnaddress popped from thestack should be a reliable methodagainst rop at-tacks.modulenamen1#n2#ntdll.d

18、ll6528138 (2.11%)ieframe.dll452322109 (4.66%)bib.dll5966317 (5.31%)aswengin.dll508951547 (3.03%)table1:numberof gadgetsprecededbyrela-tive, memoryindirect,registerindirectprocedure-call instruction(minimal/notextendedaddress-ing mode assumed).where:? n1represents totalnumberof gadgets? n2represents

19、numberof gadgets preceded bythe procedure-callinstruction? gadget represents a valid single instructionorsequence of instructionswithoutany special?lteringappliedregardingthe gadget useful-nesshowever, the methoditself has some drawbacks.call instructionscan be encoded in variousways(relative,absolu

20、te,indirect),whichcan in?uencethe scanner sperformanceand also the potentialreliabilityof thismethod.secondly,onlyorigi-nal returninstructionscan be protected.in otherwords,usingdi?erentinstructions(likeindirectjumpsor calls)forlinkinggadgetswillbe notdetected.ontheotherhand,thecall opcodechecking m

21、ethod can be based on opcode-frequencystatistics,which could decrease the potentialper-formanceslowdown.additionally,since only spec-i?ed (valuablefor attacker)returninstructionscanbe protected,this should have a positivein?uencefor the program s performance.3.1.2emittingmagicvaluesthismethodwas int

22、roducedby the pax team 5and it relies on emittingmagic bytes aftereverycalleeepilogue:movregister,esp cmp register+1 , magicjnz.1retn.1 :jmpespcaller:callcalleetesteax , magiclisting1: protectionof the execution?ow changesvia the returninstructions.call instructionand testing them at the functionepi

23、logue, as shown in listing1.this methodseems to be more reliable than themethoddescribed in section 3.1.1, althoughit alsohas some majordrawbacks.firstof all, the testinstructionisn tneutralfortheapplicationcon-text sstate, since the eflagsregister is modi?ed bythis instruction.this ?aw3, however, c

24、an be easily?xed by simplyemittingjmp over_magic instruc-tionafter each call. a more serious limitationofthis methodis the fact that every module used bythe applicationwould have to be created (compiledand linked)withthe same magic value.thisisnecessary since executiontransfers may occur fromone mod

25、ule to another4.since thisapproach wouldbe almostimpossibleto implementin the real world there is anotherso-lutionwhichcan be used here.we proposethatwindows portableexecutableloader be responsi-ble for synchronizingevery magicvalue after eachsystem boot (and after speci?ed module is loaded).this wo

26、uld of course require creating a new section(or some new, speci?c data directory)with all themagicvalues o?sets that should be updatedby theexecutableloader.3.2obfuscatinginstructionsthis approach addresses the problem where the retinstructionopcode is a part of di?erentinstruction(typicallyitis loc

27、atedamong the ?rst1-3 bytes,3whetherthisis a ?awor notdependsmostlyon theapplicationbinaryinterface;inmostcases thecalleris re-sponsiblefor savingthe ?ags.4modulesthatdont performexecutiontransfersto othermodulescan be left“unsynchronized”.3not includinginstructionopcode).owingto ourtests and extern

28、alsources 7 most of such opcodesare foundin the modr/mbyte.a second largesource of ret opcodes is found in immediatedis-placements.in ordertopreventfrome?ectivelyusingsuch cases in the ropattackwe proposethatevery instructionwithret opcode insideofits bodywillbe obfuscatedin a specialmanner.of cours

29、e controltransferinstructionsor any otherinstructionsthatuse immediatedata o?sets are anexception to this rule since the immediatedisplace-ments are calculatedby the linker.the potentialobfuscationcan be done in followingfashion:? ifret opcode is found in the ?rstbyte aftertheoriginalinstructionopco

30、de, a jumplandshould be emittedjust before this instruction.such jumpland should consist of a short un-conditionaljumpinstructionand a land(upto 16 bytes) of int3 or other worthless for at-tackersingle byte instructions.such emittedinstructionswill never be executed by the orig-inal program ?ow beca

31、use of the unconditionaljump,whichtransfersthe executiondirectlyto the potentiallydangerous instruction.suchactionshould decrease the number of e?ectivegadgets used for creatingthe rop chain.? if ret opcode is spotted in immediateconstantvalues such instructionshouldbe obfuscatedfor exampleby splitt

32、ingadd reg,imm32 intotwo addinstructionswhere the imm32 operandfor bothof themwouldbe free of returnin-structionopcodes. of course special care mustbe takenregardingthe eflagsregisterstateafter each such transition.? ifret opcodeisfoundinmodr/mbyte,whichindicatesusingeax registeras desti-nationopera

33、ndandebx registeras sourceoperand (e.g., moveax,ebx), such instructionscan be transformedinto equivalentform whichdoesnt includereturninstructionopcodes.for example moveax,ebx ?push ebx; popeax (0 x530 x58).as previouslymentioned,the presented solutionscan only be applied to instructionsthat do not

34、useimmediatedisplacements,as those are handled bythe linker.1:movesp , eaxret2:xchgeax , espret3:addesp ,retlisting2: typicalstack pivot sequences.4binary-levelmitigationsin this section we present mitigationsagainst ropattacksthatcan be appliedwithoutany informa-tion of the program s original sourc

35、e code. all miti-gations included in this section can be implementedat the binary-level.4.1stackencapsulationto make a rop attackwork, the attackermust beable to pointthe stack pointerinto the controlleddata.in typicalstack-bu?erover?ow vulnerabili-ties thisis not needed, but in other vulnerabilitie

36、s(e.g., heap-over?ow)thisis often a must.in orderto achieve this goal, the attackersuse the so calledstack pivot sequence 1. listing2 shows some com-monlyused stack pivotsequences. our mechanismtries to take advantage of this information.when a new thread is created, operatingsystemsreserve some nec

37、essary space for its stack memory.stackbordersare describedin theinitial_tebstructurewhichis passed in one of parameterofntcreatethreadfunction.additionallystack bor-ders are also availablein the threadinformationblock (fs:0 x04- top stack, fs:0 x08- currentbottomstack).when the attackeruses the piv

38、otsequence he typicallyexceeds the stack border lim-its set by the threadinitializationprocedure.themethodsdescribedin the followingsections weredesigned to recognize this behavior.similarsup-port must be taken when dealing with?bers, sincethey also use separate stacks.4.1.1newstacksegmentdescriptor

39、microsoftwindowssystems allow usermode appli-cationsto create theirown localdescriptortable(ldt).most currentoperatingsystems use the ?atmemorymodel,where there is no need to create4xoreax , eaxleaedi,esp + value stosdstosd.listing3: typicalprograminstructions.additionalsegments for every runningapp

40、lication.thiswould be in fact a step back to the old seg-mented memorymodel. on windowsplatforms,inusermode, all segments base addresses are equal tozero, except the one pointedby the fs register (thegssegment registeris not used5).in our mitiga-tion mechanism we have developed two approachesthatpro

41、tectthe system against the stack pivotingtechnique.ourinitialtechniquewas to create astack segmentdescriptoreach timenew a threadis created witha base address equal to the stackbottomand limitcorrespondingto stack size. af-ter the new segment is created we initializethe sssegment register witha new

42、value.this methodhowever has a big drawback,whichis explained on the listingbelow (listing3).thelea instructionis responsiblefor initializ-ing the edi registerwiththe e?ectiveaddress ofesp+value . however, the value thatwill be storedin the edi register is still relativeto the stack seg-ment base ad

43、dress (whichis not null in our case).the problems start with instructionsthat dont usethe ss segment registerfor addressingpurposes.for example, the stosdinstructionusesthe es seg-mentregister;its executionwillend withan ac-cess violation,since thebase address of the seg-mentpointedby es segment reg

44、isteris di?erent.in other words the lea instructiondoes not honorthe segment registers when calculatingthe e?ectiveaddress.to resolve this issue we were forced to change thebase address of the newly created stack segments.to avoid unnecessaryaccess violations,the stacksegment base address was set to

45、 zero and its limitwas set to the stack stop value. this has some dis-advantages, since the attacker would need to initial-ize new stack pointervalue with an address higherthanthe segment limitto triggerthe mechanism.most of the time, however, newlyallocated bu?ershave higher addresses since the thr

46、ead sstack mem-5thisis truefor x86-32architecturesonlyory allocationwas done earlier (there are a few ob-vious exceptionsto this rule).each timethe at-tacker tries to exceed the boundaries of the currentstack segment a general protectionfault occurs and,at this point,our ?lteringprocedure decides if

47、 theselected process is being exploitedand needs to beterminated.as a side note, there is one small problemwiththismethod.instructionsthatuse the ebp regis-ter for memoryaddressing are also using the stacksegment speci?ed by the currentsegment selector.thismeans thatif the ebp is not relatedto thest

48、ack memoryand the destinationaddress exceedsthe stack segment boundariesa general protectionfaultwilloccur.such cases however can be eas-ily ?lteredand the executioncan be resumed afteremulatingthe faultinginstruction.countermeasuresin order to bypass the stackencapsulationprotection,an attackerwoul

49、dneedto initializethe stack pointerwith a lower memoryaddress than the stack stop value. for example at-tacker can heap-spray the memoryand then causethe applicationto create a new thread thatwill beused to triggerthe vulnerability.by doing this at-tacker fake stack will be below the stack base. an-

50、other way would be to execute a gadget that reini-tializesthe stack segment withthe originalvalue(constantbetweenwindowsversions)by, for ex-ample, executinga pop ss instruction.to disablethis attackwe are constantlymonitoringthe valueof the ss segment register, and we reinitializeit ev-ery time exec

51、ution returnsfrom a system call (sincekernel reinitializesthe segment registers values be-fore the controlis returnedto the usermode).4.1.2monitoringstackpointerchangesanotherapproachfor detectingthe stack pivotingtechniqueis to monitorthe stack pointervalue atcrucialareas. for example,insteadof set

52、tingan-other segment for stack space we can hook impor-tanto?ensive apifunctions(e.g., virtualalloc,virtualprotect) and test the stack pointervaluethere.obviously,there is no guaranteethattheattackerwouldn t be able to restorethe originalstack pointerbefore using such apifunctions.toimprovethe secur

53、itylevel of this protectionmech-anism we also propose thatnewly allocatedmem-ory regions (or memoryregions with changed page5protectionrights)withexecutable pages should bemarked as non-executable6. now the page markedas non-executableby our mechanism will work as adecoy. if the processor is tryingt

54、o execute the non-executablepage (page protectionwas previouslychanged by our mechanism)then we ?rstlyapplyour ?lteringprocedure which tests the stack pointervalue. if everythingis correct, the executable rightsare re-enabled and the execution is continued theentire mechanismworks like a one-time de

55、coy.4.2codeencapsulationthe rop technique,just like any other, has somestrategic points.one of those is the fact that the at-tacker must know the virtualaddresses of the usedgadgets. because so, the aslr mechanism success-fullyobstructsthe exploitationprocess. however,in some cases the attacked appl

56、icationis either notcompatiblewithaslror justuses externalmod-ules whichdo not supportthe aslrmechanism.thereare also cases where the attackeris able toleak or guess the wanted virtualaddress, renderingthe aslrmechanism relativelyeasy to bypass. inthis section we present a mechanism which will takea

57、dvantage of this (rop)techniquesweak spot.as stated in section 4.1.1, windowssystems al-low usermode applicationsto create theirown lo-cal descriptortables.in thismechanismwe pro-pose thateach loaded modules code in the appli-cation saddress space (includingthe mainmod-ule) will have a separate segm

58、ent for code sections7,as figure2 shows. each timea executiontransferbetween modules or executiontransferusing a fullvirtualaddress (includingmodule imagebase value)occurs, a general protectionfaultwillhappen.atthispointthe ?lteringproceduredecides whetherthis execution transfer attemptis valid or a

59、n attackattempt.this methodhas some drawbacks:? a lot of control transfers are done throughapicalls and since theyrequirea code segmentswitch a general protectionfault is thrownev-erytimesuch actionoccurs.since thishasa negativeimpacton theapplicationsper-formance,entire importaddress tableentries6t

60、hisrequireshavinga cpuwithnxbitsupport7thismechanismis a bitsimilarto paxsegmexec6figure 2: not-encapsulatedand encapsulated mod-ules inside of the process memory.should be redirectedto speci?c apistubs asshown in listing4.this solutionshould successfullydecrease thenegativeperformanceimpactbecause