Security Mitigations for Return-Oriented Programming Attacks
Piotr Bania
Kryptos Logic Rearch
新生日记2010
Abstract
With the discovery of new exploit techniques,new protection mechanisms are needed as well.Mit-igations like DEP(Data Execution Prevention) or ASLR(Address Space Layout Randomization) created a significantly more difficult environment for vulnerability exploitation.Attackers,however, have recently developed new exploitation methods which are capable of bypassing the operating sys-tem’s curity protection mechanisms.
In this paper we prent a short summary of novel and known mitigation techniques against return-oriented programming(ROP)attacks.The techniques described in this article are related mostly to x86-321processors and Microsoft Win-dows operating systems.
1Introduction
In order to increa the curity level of the op-erating system,Microsoft has implemented veral mitigation mechanisms,such as DEP and ASLR. Data Execution Prevention(DEP)is a curity fea-ture that prohibits the application from executing code from non-executable memory area.To ex-ploit a vulnerability,an attacker mustfind a ex-ecutable memory region and be able tofill it with necessary ,shellcode instructions).Gen-erally,achieving this goal using old exploitation techniques is made significantly more difficult with the addition of the DEP mechanism.As a result, attackers improved upon the classic“return-into-1Some of the techniques can be also applied on other ar-chitectures,albeit some of them are only available for x86-32 ,the ones bad on creating new gment descrip-tors).
libc”technique and started using return-oriented programming(ROP)[3,7]to bypass Data Execu-tion Prevention.
Techniques like ROP are still bad on the at-tacker understanding memory layout characteris-tics,leading Microsoft to implement Address Space Layout Randomization(ASLR)as a countermea-sure.ASLR renders the layout of an application’s address space less predictable becau it relocate
s the ba address of executable modules and other memory mappings.In order to bypass DEP protec-tion mechanism ROP technique was introduced.In this article we prent novel and known mechanisms which are created specifically to prevent attackers from exploiting vulnerabilities bad on the ROP method.Prented mitigations will be divided in two general categories:
•Compiler-level mitigations—mitigations that
can be only applied by the compiler or linker.
•Binary-level mitigations—mitigations that
can be applied without knowing the source
code of the protected code fragment.
2Return-oriented Program-ming
Return-oriented programming is a known exploita-tion technique which allows the attacker to u stack memory to indirectly execute previously picked instructions(so called gadgets).Typically each gadget ends with the x86subroutine return instruction2(RET),which further transfers the ex-ecution to the next gadget or the payload itlf.
失败乃成功之母作文
2However other instructions may be ud as well like jmp reg,call reg etc.
1
For more information regarding the return-oriented programming technique plea refer to[1,3,7].
3Compiler-level mitigations In this ction we prent ROP protection mecha-nisms which can be applied at the compiler-level. However this doesn’t mean they are not imple-mentable at the binary-level-they are simply sub-stantially easier to implement at the compiler-level. We will also try to underline advantages and dis-advantages of described mechanisms.
The biggest disadvantage of compiler-level miti-gations is the fact that they require code recompi-lation in order to be effective.It is often hard to quickly implement such kind of changes in the real world.
3.1Call-Ret relations
As previously stated,most gadgets u return instructions to transfer execution control to an-other gadget or payload.In order tofind uful gadgets,attackers scan the process memory or the binary module for return instruction opcodes and, after such opcode is found,they try to perform backward d
isasmbly in order to decide whether following gadget is uful(correct)or not.Return instruction opcodes can often be found in the middle of different instructions.Results,how-ever,show that most of the time original return instructions RET are ud.Typically they also reprent the highest number of return opcodes found in the entire module’s executable area (cf.Figure1).For the remainder of this article RET instructions emitted in the original program’s code will be named as“original return instruction”.
中国十大女杰
3.1.1Testing for CALLs
In typical applications,every procedure(function) is executed by using call-procedure instruction.Ev-ery CALL instruction saves procedure linking infor-mation on the stack and branches to the procedure specified by the destination operand.Our ROP mitigation technique relies on a fact that each re-turn address popped from the stack by the RET in-struction is preceded by CALL instruction.
When
Figure1:RET opcode offts in sample modules (offt equal to1indicates that this is an original RET instruction).
2
a ROP attack occurs the return address points to another gadget(orfinally a payload).It is unlikely that an attacker will be able to pick the return ad-dress preceded by CALL instruction operands(e Table1for details).Testing for CALL instructions located before the return address popped from the stack should be a reliable method against ROP at-tacks.
Module Name N1[#]N2[#]
ntdll.dll6528138(2.11%)
ieframe.dll452322109(4.66%)梦见蝙蝠
bib.dll5966317(5.31%)
aswEngin.dll508951547(3.03%) Table1:Number of gadgets preceded by rela-tive,memory indirect,register indirect procedure-call instruction("minimal/not extended"address-ing mode assumed).
Where:
•N1reprents total number of gadgets
•N2reprents number of gadgets preceded by the procedure-call instruction
•gadget reprents a valid single instruction or quence of instructions without any special filtering applied regarding the gadget uful-ness皮肤太怎么办
However,the method itlf has some drawbacks. CALL instructions can be encoded in various ways (relative,absolute,indirect),which can influence the scanner’s performance and also the potential reliability of this method.Secondly,only origi-nal return instructions can be protected.In other words,using different instructions(like indirect jumps or calls)for linking gadgets will be not detected.On the other hand,the CALL opcode checking method can be bad on opcode-frequency statistics,which could decrea the potential per-formance slowdown.Additionally,since only spec-ifie
d(valuable for attacker)return instructions can be protected,this should have a positive influence for the program’s performance.
3.1.2Emitting magic values
即兴主持This method was introduced by the Pax Team[5] and it relies on emitting magic bytes after every
callee
epilogue:
mov register,[esp]
cmp[register+1],MAGIC
jnz.1
retn
.1:jmp esp
caller:
call callee
test eax,MAGIC
Listing1:Protection of the executionflow changes via the return instructions.
CALL instruction and testing them at the function epilogue,as shown in Listing1.
This method ems to be more reliable than the method described in Section3.1.1,although it also has some major drawbacks.First of all,the TEST instruction isn’t neutral for the application con-text’s state,since the EFLAGS register is modified by this instruction.Thisflaw3,however,can be easily fixed by simply emitting JMP OVER_MAGIC instruc-tion after each CALL.A more rious limitation of this method is the fact that every module ud by the application would have to be created(compiled and linked)with the same MAGIC value.This is necessary since execution transfers may occur from one module to another4.
支付安全Since this approach would be almost impossible to implement in the real world there is another so-lution which can be ud here.We propo that Windows’Portable Executable loader be responsi-ble for synchronizing every MAGIC value after each system boot(and after specified module is loaded).
This would of cour require creating a new ction (or some new,specific data directory)with all the MAGIC values offts that should be updated by the executable loader.
3.2Obfuscating instructions
This approach address the problem where the RET instruction opcode is a part of different instruction (typically it is located among thefirst1-3bytes,
3Whether this is aflaw or not depends mostly on the application binary interface;in most cas the caller is re-sponsible for saving theflags.
4Modules that don’t perform execution transfers to other modules can be left“unsynchronized”.
3
not including instruction opcode).Owing to our tests and external sources[7]most of such opcodes are found in the ModR/M byte.A cond large source of RET opcodes is found in immediate dis-placements.In order to prevent from effectively using such cas in the ROP attack we propo that every instruction with RET opcode inside of its body will be obfuscated in a special manner. Of cour control transfer instructions or any other instructions that u immediate data offts are an e
xception to this rule since the immediate displace-ments are calculated by the linker.The potential obfuscation can be done in following fashion:
•If RET opcode is found in thefirst byte after the original instruction opcode,a jump land should be emitted just before this instruction.
Such jump land should consist of a short un-conditional jump instruction and a land(up to16bytes)of INT3or other worthless for at-tacker single byte instructions.Such emitted instructions will never be executed by the orig-inal programflow becau of the unconditional jump,which transfers the execution directly to the potentially dangerous instruction.Such action should decrea the number of effective gadgets ud for creating the ROP chain.
•If RET opcode is spotted in immediate constant values such instruction should be obfuscated for example by splitting ADD REG,IMM32into two ADD instructions where the IMM32operand for both of them would be free of return in-struction opcodes.Of cour special care must be taken regarding the EFLAGS register state after each such transition.
•If RET opcode is found in ModR/M byte, which indicates using EAX register as desti-nation operand and EBX register as source ,MOV EAX,EBX),such instructions can be transformed into
equivalent form which doesn’t include return instruction opcodes.
For example MOV EAX,EBX↔PUSH EBX;POP EAX(0x530x58).
As previously mentioned,the prented solutions can only be applied to instructions that do not u immediate displacements,as tho are handled by the linker.
1:mov esp,eax
ret
2:xchg eax,esp
ret
3:add esp,<number>
ret
Listing2:Typical stack pivot quences.
4Binary-level mitigations
In this ction we prent mitigations against ROP attacks that can be applied without any informa-tion of the program’s original source code.All miti-gations included in this ction can be implemented at the binary-level.
4.1Stack Encapsulation
To make a ROP attack work,the attacker must be able to point the stack pointer into the controlled data.In typical stack-buffer overflow vulnerabili-ties this is not needed,but in other vulnerabilities (e.g.,heap-overflow)this is often a must.In order to achieve this goal,the attackers u the so called stack pivot quence[1].Listing2shows some com-monly ud stack pivot quences.Our mechanism tries to take advantage of this information.加班说说
When a new thread is created,operating systems rerve some necessary space for its stack memory. Stack borders are described in the INITIAL_TEB structure which is pasd in one of parameter of NtCreateThread function.Additionally stack bor-ders are also available in the Thread Information Block(FS:[0x04]-top stack,FS:[0x08]-current bottom stack).When the attacker us the pivot quence he typically exceeds the stack border lim-its t by the thread initialization procedure.The methods described in the following ctions were designed to recognize this behavior.
Similar sup-port must be taken when dealing withfibers,since they also u parate stacks.
4.1.1New stack gment descriptor Microsoft Windows systems allow urmode appli-cations to create their own local descriptor table (LDT).Most current operating systems u theflat memory model,where there is no need to create
4
xor eax,eax
lea edi,[esp+VALUE]
stosd
stosd
...
Listing3:Typical program instructions. additional gments for every running application. This would be in fact a step back to the old g-mented memory model.On Windows platforms,in urmode,all s
egments’ba address are equal to zero,except the one pointed by the FS register(the GS gment register is not ud5).In our mitiga-tion mechanism we have developed two approaches that protect the system against the stack pivoting technique.Our initial technique was to create a stack gment descriptor each time new a thread is created with a ba address equal to the stack bottom and limit corresponding to stack size.Af-ter the new gment is created we initialize the SS gment register with a new value.
This method however has a big drawback,which is explained on the listing below(Listing3).
The LEA instruction is responsible for initializ-ing the EDI register with the effective address of ESP+VALUE.However,the value that will be stored in the EDI register is still relative to the stack g-ment ba address(which is not null in our ca). The problems start with instructions that don’t u the SS gment register for addressing purpos. For example,the STOSD instruction us the ES g-ment register;its execution will end with an ac-cess violation,since the ba address of the g-ment pointed by ES gment register is different. In other words the LEA instruction does not honor the gment registers when calculating the effective address.
To resolve this issue we were forced to change the ba address of the newly created stack gmen
ts. To avoid unnecessary access violations,the stack gment ba address was t to zero and its limit was t to the stack’s top value.This has some dis-advantages,since the attacker would need to initial-ize new stack pointer value with an address higher than the gment limit to trigger the mechanism. Most of the time,however,newly allocated buffers have higher address since the thread’s stack mem-5This is true for x86-32architectures only
ory allocation was done earlier(there are a few ob-vious exceptions to this rule).Each time the at-tacker tries to exceed the boundaries of the current stack gment a general protection fault occurs and, at this point,ourfiltering procedure decides if the lected process is being exploited and needs to be terminated.
As a side note,there is one small problem with this method.Instructions that u the EBP regis-ter for memory addressing are also using the stack gment specified by the current gment lector. This means that if the EBP is not related to the stack memory and the destination address exceeds the stack gment boundaries a general protection fault will occur.Such cas however can be eas-ilyfiltered and the execution can be resumed after emulating the faulting instruction. Countermeasures In order to bypass the stack encapsulation protection,an attacker would need to initialize the stack pointer with a lower memory address than the stack’s top value.For example at-ta
cker can heap-spray the memory and then cau the application to create a new thread that will be ud to trigger the vulnerability.By doing this at-tacker fake stack will be below the stack ba.An-other way would be to execute a gadget that reini-tializes the stack gment with the original value (constant between Windows versions)by,for ex-ample,executing a POP SS instruction.To disable this attack we are constantly monitoring the value of the SS gment register,and we reinitialize it ev-ery time execution returns from a system call(since kernel reinitializes the gment registers values be-fore the control is returned to the urmode).
4.1.2Monitoring stack pointer changes Another approach for detecting the stack pivoting technique is to monitor the stack pointer value at crucial areas.For example,instead of tting an-other gment for stack space we can hook impor-tant offensive API ,VirtualAlloc, VirtualProtect)and test the stack pointer value there.Obviously,there is no guarantee that the attacker wouldn’t be able to restore the original stack pointer before using such API functions.To improve the curity level of this protection mech-anism we also propo that newly allocated mem-ory regions(or memory regions with changed page 5
