If I read this correctly, they’re “bypassing ASLR” because the binary isn’t PIE, so it’s loaded at a static address.
I would not consider this actually bypassing ASLR, because ASLR is already turned off for a critically important block of code. Practically any large-enough binary has gadgets that can be useful for ROP exploitation, even if chaining them together is somewhat painful. For ASLR to be a reasonably effective mitigation, every memory region needs to be randomized.
Yeah :/ that’s how I read it too. It would make more sense if they motivated the reason to find libc because like you said you could likely just use the non aslr gadgets exclusively. I think the author tried to use non aslr gadgets but had issues so went to the approach of using the GOT libc address and called that approach “bypassing ASLR”.
It’s a matter of opinion I guess. In the early days of ASLR it was common to look for modules that were not position independent for your ROP chain and that process was probably called bypassing aslr. These days we’d probably just call that not being protected by aslr.
This is a bit interesting in how it doesn't require further interactivity with the attacker once the libc address has been obtained, unlike most basic ROP examples, which I've rarely seen require anything fancier than return-to-main. The more the chain does in a single pass, the more it might need gadgets smarter than "set register to immediate and return".
The most shocking part is the absence of stack canaries. I know there are issues with them on microcontrollers, but still I would assume they’re enabled by default by the compiler.
You typically don't see ASLR enabled on these armhf embedded devices. I see the statement by the author, " quickly confirmed on the device that address space layout randomization (ASLR) was enabled...", but how was it quickly checked? What was the output of /proc/sys/kernel/randomize_va_space?
Also not familiar at all with the checksec program, but from my look at the documentation, you expect to see PIE enabled not DSO (which implies dynamic shared object).
Good job. It’s early 2000s level stuff but it’s still exciting when it’s happening on your desk. There are lots of options in this scenario outside of bypassing ASLR so I do find it odd to be the main feature of the title, but a fun read nonetheless.
It’s fun working on targets with a less established research history. And I love a soup to nuts writeup, Thanks.
If I read this correctly, they’re “bypassing ASLR” because the binary isn’t PIE, so it’s loaded at a static address.
I would not consider this actually bypassing ASLR, because ASLR is already turned off for a critically important block of code. Practically any large-enough binary has gadgets that can be useful for ROP exploitation, even if chaining them together is somewhat painful. For ASLR to be a reasonably effective mitigation, every memory region needs to be randomized.
Yeah :/ that’s how I read it too. It would make more sense if they motivated the reason to find libc because like you said you could likely just use the non aslr gadgets exclusively. I think the author tried to use non aslr gadgets but had issues so went to the approach of using the GOT libc address and called that approach “bypassing ASLR”.
It’s a matter of opinion I guess. In the early days of ASLR it was common to look for modules that were not position independent for your ROP chain and that process was probably called bypassing aslr. These days we’d probably just call that not being protected by aslr.
you can't just use gadgets from the binary and pop a shell, if it was possible the author would have done it, they needed to ret2libc.
This is a bit interesting in how it doesn't require further interactivity with the attacker once the libc address has been obtained, unlike most basic ROP examples, which I've rarely seen require anything fancier than return-to-main. The more the chain does in a single pass, the more it might need gadgets smarter than "set register to immediate and return".
The most shocking part is the absence of stack canaries. I know there are issues with them on microcontrollers, but still I would assume they’re enabled by default by the compiler.
You typically don't see ASLR enabled on these armhf embedded devices. I see the statement by the author, " quickly confirmed on the device that address space layout randomization (ASLR) was enabled...", but how was it quickly checked? What was the output of /proc/sys/kernel/randomize_va_space?
Also not familiar at all with the checksec program, but from my look at the documentation, you expect to see PIE enabled not DSO (which implies dynamic shared object).
"No Leak, No Problem - Bypassing Address Space Layout Randomization with a Return-Oriented Programming Chain to Gain Remote Code Execution"
Expanding it, perhaps to the benefit of others like me.
Good job. It’s early 2000s level stuff but it’s still exciting when it’s happening on your desk. There are lots of options in this scenario outside of bypassing ASLR so I do find it odd to be the main feature of the title, but a fun read nonetheless.
It’s fun working on targets with a less established research history. And I love a soup to nuts writeup, Thanks.