[HN Gopher] No Leak, No Problem - Bypassing ASLR with a ROP Chai...
___________________________________________________________________
No Leak, No Problem - Bypassing ASLR with a ROP Chain to Gain RCE
Author : todsacerdoti
Score : 108 points
Date : 2025-11-14 23:39 UTC (23 hours ago)
(HTM) web link (modzero.com)
(TXT) w3m dump (modzero.com)
| OneLessThing wrote:
| 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.
| nneonneo wrote:
| 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.
| OneLessThing wrote:
| 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.
| aziz_k wrote:
| 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.
| LegionMammal978 wrote:
| 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".
| alchemio wrote:
| 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.
| BiraIgnacio wrote:
| "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.
| kingforaday wrote:
| 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).
| alchemio wrote:
| checksec is part of the pwntools suite. Along with other tools
| for finding ROP gadgets and shellcode generation.
___________________________________________________________________
(page generated 2025-11-15 23:01 UTC)