Abstract— Computer security is aprogress in which attackers find ways to exploit and defenders find ways todefend against them, so on and on.
Prior assumption before the introduction ofreturn-into-libc attacks was that to create malicious behaviors, the attackerneeds to be able to inject bad code into the target system. Return-into-libcattacks proved this assumption to be wrong and Return-Oriented Programming evenmade it one step further than return-into-libc that this technique asreturn-into-libc attacks uses existing code in the target system to createarbitrary behavior but it does not use any function calls or limited to libc,it is architecture independent and, it can bypass traditional defensivemeasures. In response, the security community came up with some suggestions todefeat ROP. This document briefly introduces and describes ROP and somemitigations against it.Keywords—return-oriented programming, g-free, aslr, dep I. IntroductionOne false assumption that the security community made wasmalicious activity can be blocked by preventing introduction of malicious codeto the system. Since it is not possible to accurately classify an execution asharmful, some parts of the security community focused on attempting to isolatethe injected code with memory protection methods.
Return oriented programmingis an advanced technique that falsifies this assumption by being able tointroduce malicious activity without injecting any harmful code independent ofthe underlying architecture. ROP is a generalization of return-into-libcattacks which has been introduced to defy memory protections developed againstclassical stack buffer overflow attacks such as stack smashing. In classicstack smashing attacks, assuming there are no memory protections, attackerusually finds a bug in a program which can be exploited to inject maliciouscode (e.g.
reverse shell payload) into the stack by overwriting the adjacentmemory blocks and diverts the flow of the program to execute it 1, pp. 3-4.In detail, attacker tries to control the program counter register (EIP) whilestoring the payload somewhere in the memory then points to the injected code byoverwriting EIP’s address since buffer is allocated contiguously in the stack.In response, W?X (Write-XOR-eXecute) memoryprotection techniques such as NX and DEP have been developed to overcome thistype of attacks. Briefly W?X type of defensesmark the partitions of the memory either as writable or executable but not both2, pp.
Best services for writing your paper according to Trustpilot
2. This same approach also implemented in hardware level as NX bit(No-eXecute) by companies such as Intel and AMD but in this case, theyintroduced an executable bit that indicates whether if the memory area iseither dedicated for storage or processor instructions. DEP stands for DataExecution Prevention, it is Windows’ version of W?X memory protectionbut on system level. Same approach is also used by Linux and macOS.
To defeat W?X type protections, instead of code injectingattackers use existing functions of libc in the target system, this type ofapproach first suggested by Solar Designer 3. In Unix systems, standard Clibrary contains system methods such as file I/O and, file execution and it islinked by almost all Unix C programs. For this attack to be successful, theattacker still needs to be able to subvert a program flow as it was before withstack buffer overflow attacks but this time, the adversary uses existing codein the target system. ROP is a generalization of return-into-libc that does notrely on function calls, instead it can build instruction chains with theexisting code in the target system without making any function calls. ROP is avery effective technique which applied by malwares such as Stuxnet and Duqu 45.Some defenses have been developed to stop this attack such as ASLR, G-Free and,IB-MAC 6 (for IoT embedded systems).
Among someof the defenses such as ASLR can be bypassed by variants 2, pp. 3 of ROP andmore advanced techniques such as G-Free remain unbroken. II. Return-OrientedProgramm?ngNowadays, ROP isaffiliated by every attack that uses existing code in the target system, thissuch approach first suggested by Solar Designer 3. However, the name ROP isfirst brought up by Hovav Shacham 2 as an attack that uses existing codesnippets ending with return statements which can be chained together to createarbitrary behavior without making any function calls. With this approach NX bitor W?X type of defenses can be bypassed. Areturn oriented program is a combination of one or more gadgets which uponexecution, creates the attacker’s desired behavior. A gadget consists of wordson the stack including single or multiple instruction sequence pointers andcorresponding immediate values, that encodes a logical unit 2 pp.
12. In x86architecture, a gadget can contain other gadgets since x86 instructions are notaligned, but this is not true for other architectures. Apart fromreturn-into-libc attack, ROP’s building blocks are not functions, rather it isshort code snippets ending with a return statement.
In theory, every codesequence ending with a return instruction is potentially useful. Easiestway to accomplish a ROP attack is to use stack buffer overflow exploits. Roadmap for ROP starts with finding suitable gadgets for the desired behavior. Forthis task, some tools have been developed since ROP’s first emergence such asRp++ 7, Nrop 8 and, ROPgadget 9. Chance of finding necessary gadgets forthe task increases as the codebase gets larger. Traditional tools find gadgetsby locating every return instruction and then walking back from theseinstructions while looking at corresponding sequence and checking forcriterions of the user or legitimacy of the instruction sequence. Correctexecution of gadgets has one precondition and one postcondition.
Theprecondition is that ESP register should point to the first word in the gadgetand the processor executes a return instruction 2, pp. 12. The postconditionis when the return instruction in its last instruction sequence is executed,ESP points to the next gadget to be executed 2, pp. 12. In the next step,stack needs to be overwritten with the payload that contains gadget addressespreviously chosen.
Key difference here from stack smashing attacks is thatthere are no processor instructions in the payload, it only consists of gadgetaddresses which will be written to the stack. Also, gadgets of a returnoriented program do not need its gadgets to be stored in adjacent memory blocksor solely in stack, furthermore gadget payload can be divided on to stack andheap. One crucial information to note is this same process applies to everyarchitecture, the only difference is the equivalent instruction semantics varyin each architecture. Recall that the attacker overwrites the stack with thepayload in such a way that it can set the EIP with the address of first gadget.Additionally, return oriented program stored in heap can be initiated byoverwriting a function pointer with the address of a code snippet that sets ESPto the address of the first gadget and executes a return. Either way the gadgetchain will be executed accordingly one by one returning to each other creatingthe desired behavior.
III. Mitigations Against RopDefenses that focus on the use of return instruction for return-orientedprogramming have been proposed. Such defenses can be defeated by using variantsof return-oriented programming which are not using return instructions 2, pp.3. There are however more complex counter measures to prevent return-orientedprogramming that focuses on control-flow integrity. These types of defensesremain unbroken. Control-flow integrity oriented security measures are alsosupported by authors of return-oriented programming 2, pp. 30.
In thissection, widespread used ASLR and a proposed defense; G-Free defined andcommented. There are numerous propositions such as hardware modifications suchas InstructionBased Memory Access Control. Also, Windows has additional mitigations such asSEHOP to prevent the attacker from diverting the flow by overwriting exceptionpointers.
DEP/NX by itself is not a defense against return-oriented programmingtherefore, it is excluded.A. AddressSpace Layout RandomizationAddress spacelayout randomization (ASLR) is used to randomize address ranges of importantmemory segments at each execution. It is developed to prevent hard-codedattacks that are using stack, heap and, libc addresses. At each executionstack, heap and, library addresses change therefore, memory segment addressesare not static anymore.
Still with a stack smash an attacker can get thecontrol of EIP but this time the attacker does not know where to go. It isapplied wide spread ranging from Android and iOS phones to desktop kernels. InLinux, ASLR does not randomize every program because PIE flag of a programneeds to be set on compile. PIE stands for Position Independent Executablewhich tells compiler that the base address does not really matter, without it,the program is not taking full advantage of ASLR thus the attacker might beable to find some gadgets. It is crucial to compile shared libs with PIE flag.
Sincesecurity is a progress, some ways to bypass ASLR have been found such asinformation disclosure 12, partial address overwrite 11 and, base addressbrute forcing 10. Information disclosure happens whenever the attacker canextract any meaningful information while ASLR is deployed. Assuming there isinfo leak regarding the address of printfmethod of libc, then the attacker can compare the distance between methods andfind the addresses of desired gadgets or methods such as execve. Furthermore, finding the necessary functions or codesnippets of libc by brute force is feasible because ASLR does not randomizeeverything, it randomizes the base addresses of each library.
B. G-FreeG-Free is acompiler based defense approach against return-oriented programming. G-Freetries to eliminate every unaligned free-branch instruction which an executablebinary contains, and to prevent misuse of existing aligned free-branchinstructions. It adds NOP instructions to align instructions and prepends aJUMP instruction to skip sled bytes.
This forces the attacker’s code to realignwith the actual code when it reaches the NOP sleds. However, this approachintroduces overheads which is going to be mentioned in the last part of thesection. Aligned instructions’ performance is not affected by this approach. Moreover,G-Free attaches a short header that encrypts the return address stored on thestack for entry points of the functions end with a RETURN instruction. Later,it inserts a footer corresponding to the header to restore the return addressto its original value 14, pp. 4. This step prevents the attacker to jump toan arbitrary position because at the end, in the footer, decryption routine iswaiting. Because of decryption step in the footer, it calculates a faultyaddress irrelevant to the attacker’s intent.
RETURN instruction then tries totransfer the flow to a bad address computed by the footer which the attackercannot control. G-Freealso makes use of Frame Cookies to prevent the attacker from using JUMP/CALLinstructions 14, pp. 5. Wherever this kind of instructions found, anadditional header is attached which computes and pushes a random cookie ontothe stack. Then again, a validation footer is attached to fetch the cookie anddetermine if the destination address is valid. Upon an invalid case, it causesapplication to crash.
G-Freecurrently remains unbroken but introduces 23% more memory usage and 3% decreasein performance 14, pp. 5. It also makes use of code rewriting techniques toremove unaligned free-branch instructions IV. ConclusionReturn-Oriented programmingproves to be very effective as it was used in popular malwares such as Stuxnetand Duqu. With this technique attackers can avoid W?Xtype of protections and furthermore with its variants they are able to defeatdefenses that focus on limiting the usage of return instructions. Suggestedmore sophisticated defenses remain unbroken but they also introduce additionaloverhead and decrease in performance. This attacking technique emphasizes theimportance of control-flow therefore, defense efforts focused on thecontrol-flow integrity would be in more effect.
ROPis independent of underlying architectures and it is Turing-complete. Gadgetfinding is still possible even though in the presence of ASLR. Since ROPprovides the attacker the benefit of using existing code in the target system,malwares become smaller therefore harder to detect by traditional defensesystems and it makes code signing useless against ROP.
Implementation ofdefenses for embedded systems are even more problematic due to the need ofextra memory and computation. As ROPproves the prior assumption of malicious behavior can only be created byinjected bad code invalid, this approach shows it is in fact possible to createarbitrary behavior by using existing code in the target system. In order tomake this approach disappear, control-flow integrity systems ought to beadopted more.
References1 J.Salwan, “An introduction to the Return Oriented Programming and ROP chaingeneration” in Shell-Storm.2 R.Roemer, E. Buchanan, H. Shacham, and S.
Savage, “Return-Oriented Programming:Systems, Languages, and Applications” ACMTransactions on Information and System Security, vol. 15, no. 1, Mar.
2012.3 SolarDesigner, “Getting around non-executable stack (and fix)”, 10-Aug-1997.Online.
Available: https://marc.info/?l=bugtraq&m=87602746719512.4 A.Matrosov, E. Rodionov, D. Harley, and J. Malcho, “Stuxnet Under theMicroscope”, Official site of theantivirus ESET NOD32, ESET. Available: https://www.
esetnod32.ru/company/viruslab/analytics/doc/Stuxnet_Under_the_Microscope.pdf5 P.
Szor, “Duqu – Threat Research and Analysis”, McAffee Labs. Available: https://securingtomorrow.mcafee.com/wp-content/uploads/2011/10/Duqu1.pdf6 A.C. A.
Francillon, D. Perito, and C. Castelluccia, “Defending Embedded SystemsAgainst Control Flow Attacks.
” Available: http://citeseerx.ist.psu.
edu/viewdoc/download?doi=10.1.1.150.3803&rep=rep1&type=pdf7 A.
Souchet, “rp++”, https://github.com/0vercl0k/rp8 A.Wailly, “Nrop”, https://github.com/awailly/nrop9 J.Salwan, “ROPgadget” in Shell-Storm10 H.
Shacham, M. Page, B. Pfaff, E. J.
GOH, N. Modadugu, and D. Boneh, “On theeffectiveness of address-space randomization.”, Proceedings of the ACM Conferenceon Computer and Communications Security (CCS’04). B. Pfitzmann and P. LiuEds.
, ACM Press, 298–307, 2014.11 T.Durden, “Bypassing PaX ASLR protection.”, 2002, Phrack Mag. 59, 9.
http://www.phrack.org/archives/59/p59_0x09_Bypassing%20PaX%20ASLR%20protection_by_Tyler%20Durden.txt.12 D.Blazakis, “Interpreter exploitation”, 2010, In Proceedings of WOOT 2010,H. Shacham and C.
Miller, Eds. USENIX13 K.Onarlioglu, L. Bilge, A.
Lanzi, D. Balzarotti, and E. Kirda, “ACSAC ’10,” in Proceedings of the 26th Annual ComputerSecurity Applications Conference, pp. 49–58.
14 J. Xu, Z. Kalbarczyk, R. K. Iyer,”Transparent runtime randomization for security”, 2003, 260- 269.
10.1109/RELDIS.2003.
1238076.
