ROP History
With the current improvements in OS security and hardware, security features like the Linux PAX project, code injection is now impossible. Security researchers then conceived a new attack which they namedScenarios for BROP
There are three new scenarios which BROP can be relevant for. They are: The attack assumes that there is a service on the server which has a known stack vulnerability and also that the service should restart on crash.Phases of attack
Stack reading
Return instruction pointers are usually protected by stack canaries. A stack canary causes the program to crash if its value is modified by a buffer overrun. In the BROP model of attack, the buffer overrun is carried byte by byte. Each try at the overrun results either in a program crash or continued execution. A program crash implies that the stack value was incorrectly guessed, therefore in 256 tries (average case is 128 tries), the stack value can be probably estimated. On 64 bit machines, 4 such stack reads would be required to leak the canary. Once the canary is leaked, the return instruction pointer can be perturbed in the same way. It may, however, be noted that though the estimation of the stack canary is exact, the same cannot be said about the return instruction address. The attacker would be satisfied to be able to leak any address within the text segment of the address space.Blind ROP
This stage is the heart of the attack. The objective in this phase is to initiate a write system call, sending a dump of the binary to the attacker. The write system call has three params: socket, buffer, and length. As x86-64 calling conventions require the parameters to be passed through registers, appropriate pop instructions into rsi, rdi and rdx would be needed to set up the arguments for the write system call. Instruction sequences like pop rdi, ret and the like would be helpful in this regard. A simple ROP version of the write system call would be: # # # # # One problem with this methodology is that even if useful gadgets are found in the address space after they return the address on the stack would lead to non-executable stack with a high probability. To remedy this, BROP proposers conceived stop gadgets. A stop gadget is anything that would cause the program to block, like an infinite loop or a blocking system call (like sleep). This also workers processors affected in the attack to be stuck in an infinite loop and hence allowing the attacker to carry on the attack. What is mentioned above is the bare-bones methodology of the attack. In reality, a few optimizations can be carried out which help in efficiently carrying out the attack. Primary among them is the use ofBuild the exploit
Once the writing is found in the PLT, the attacker can dump the contents of the target binary to find more gadgets. The attacker can use conventional ROP gadget search techniques to gather enough and create a shellcode. Once they have the shellcode, the exploited system can be taken under full control with root access.BROP prevention
A huge assumption in the BROP attack is that the server restarts after each crash and when restarting does not re-randomize its address space. So enabling re-randomization of address space at startup can provide almost complete protection against BROP. Another technique used by NetBSD and Linux is sleep on the crash. This slows down the attack considerably and allows the system administrator to look into any suspicious activity. Apart from this the conventional protection against ROP style control flow hijacking attacks, Control Flow Integrity also can provide provable prevention but at a significant performance overhead.Similar attacks
Another attack that is similar in nature to BROP, is JIT (Just-In-Time)-ROP, or JIT-ROP. It is also another attack that's based on information disclosure, which is able to also defeatReferences
{{Reflist * ''Hacking Blind'', Andrea Bittau, Adam Belay, Ali Mashtizadeh, David Mazieres, Dan Boneh * ''Return Oriented Programming'', Hovav Shacham et al. * http://www.scs.stanford.edu/brop/ * http://www.scs.stanford.edu/brop/bittau-brop.pdf * http://ytliu.info/blog/2014/05/31/blind-return-oriented-programming-brop-attack-yi/ Computer security exploits