5 ms·

A classic, but these days if you want to reproduce those bugs you need to build your code with -fno-stack-protector, enable executable stack, disable ASLR in th

by f00zz 6y ago

A classic, but these days if you want to reproduce those bugs you need to build your code with -fno-stack-protector, enable executable stack, disable ASLR in the kernel, etc.

wizzwizz4 6y ago
Not really. If you can overwrite the return address, and you have some time to plan out your payload in advance, you can write a program by “returning” into other bits of the program or its libraries.
- waynecochran 6y ago
  If you're exploit using existing code (which would be limited), but if you want to inject code you typically need to put on the stack. Maybe one could inject code into the .bss/.data section, but this is probably protected from execution as well. The .text section is probably read only.
- guerrilla 6y ago
  https://en.wikipedia.org/wiki/Return-oriented_programming https://en.wikipedia.org/wiki/Return-oriented_programming I wonder if anyone's ever automated it.
  - saagarjha 6y ago
    Fully automating ROP is difficult, but people have written many scripts to find interesting "gadgets" that set various registers and also found useful "targets" to ROP to, such as a handful of instructions inside of most libc's system command that can yield a shell if jumped to with light constraints.
- e12e 6y ago
  > you can write a program by “returning” into other bits of the program or its libraries. Phrack has you covered, eg: from 2001: The advanced return-into-lib(c) exploits: PaX case study by Nergal <nergal@owl.openwall.com> http://phrack.org/issues/58/4.html#article http://phrack.org/issues/58/4.html#article Think I actually looked at this and an (at the time) recent 0day for opensshd that was found and written up by a couple of Finnish students - as a motivational presentation for PaX and/or grsecurity while at university.
  - saagarjha 6y ago
    Taken to the extreme, you have ROP: https://hovav.net/ucsd/dist/geometry.pdf https://hovav.net/ucsd/dist/geometry.pdf
- hyper_reality 6y ago
  Return Oriented Programming (ROP) can bypass the non-executable stack protection, since existing "gadgets" from program memory are executed rather than attacker-provided shellcode. However the stack protection will probably require a separate information leak (to find the canary value) or arbitrary write (to overwrite it) to bypass. Unless the attacker is fortunate to find an unprotected function which the compiler missed, or a value that can be overwritten which changes the control flow and isn't protected by the canary. ASLR is also a decent mitigation against ROP, and requires an information leak so the exploit code can calculate the memory offset to find the library gadgets. In short, ROP isn't the solution to all the mitigations the parent posted; in fact ASLR is designed to make ROP harder to exploit.
  - saagarjha 6y ago
    And, if your hardware supports it, PAC and shadow stacks can help protect your return addresses too.
  - wizzwizz4 6y ago
    > Unless the attacker is fortunate to find an unprotected function which the compiler missed, Every instance of the bytes C3, CB, C2 or CA in the executable page could potentially be abused, via carefully-chosen instruction alignment.
stevekemp 6y ago
Very much so. I wrote a couple of simple "exploiters" for particular bad-patterns I saw, shortly after reading this piece: https://steve.fi/security/exploits/ https://steve.fi/security/exploits/ These days these things are less useful, but recreating known-exploits is still educational. Once you get buffer-overflows handled you can look for more exotic things, format-string attacks, and similar.
- e12e 6y ago
  Oh, I didn't realize you were based in Finland - and only now realized why I've not seen any articles from the Deb adm site in a long while: http://web.archive.org/web/20190325214351/https://debian-administration.org/article/730/This_site_is_going_to_go_read-only http://web.archive.org/web/20190325214351/https://debian-adm... Without going too far side-tracked: I think the Arch wiki has demonstrated that a community wiki can be very useful - I do hope people continue to contribute to the Debian wiki (although I find myself mostly on Ubuntu of late). Anyway, there's a certain path from phrack through debian-administration.org that maps out where I find myself today, so happy coincidence to see the two line up in the threads.
  - stevekemp 6y ago
    I moved from Edinburgh, Scotland, to Helsinki about five years ago. (I'm actually going to complete my post-Brexit registration to retain permanent residency this afternoon!) The arch wiki has been very useful to me over the past few years, I guess the barrier to entry there is lower for contributors. On my site I had a fair number of people writing interesting blog-posts, and comments, but only very very rarely did anybody submit an article. I felt like I had a good niche audience, but sadly never quite enough people to keep me really motivated. I'm just glad I managed to setup the redirects to the wayback machine - I feel like if the site disappeared for good I'd have lost a chunk of my life!
ahepp 6y ago
I'm trying to remember where, but I once saw this article presented with a very nice guide to replicating the exploits in a VM on a modern computer. I think it must have been in university, unfortunately when I look up the course number, the resources seem to be (understandably, I suppose) date gated.
navbaker 6y ago
I believe Hacking: The Art of Exploitation comes with a disc that has an exploitable image on it.

by f00zz 6y ago

A classic, but these days if you want to reproduce those bugs you need to build your code with -fno-stack-protector, enable executable stack, disable ASLR in the kernel, etc.

wizzwizz4 6y ago

Not really. If you can overwrite the return address, and you have some time to plan out your payload in advance, you can write a program by “returning” into other bits of the program or its libraries.

waynecochran 6y ago
If you're exploit using existing code (which would be limited), but if you want to inject code you typically need to put on the stack. Maybe one could inject code into the .bss/.data section, but this is probably protected from execution as well. The .text section is probably read only.
guerrilla 6y ago
https://en.wikipedia.org/wiki/Return-oriented_programming https://en.wikipedia.org/wiki/Return-oriented_programming I wonder if anyone's ever automated it.
- saagarjha 6y ago
  Fully automating ROP is difficult, but people have written many scripts to find interesting "gadgets" that set various registers and also found useful "targets" to ROP to, such as a handful of instructions inside of most libc's system command that can yield a shell if jumped to with light constraints.
e12e 6y ago
> you can write a program by “returning” into other bits of the program or its libraries. Phrack has you covered, eg: from 2001: The advanced return-into-lib(c) exploits: PaX case study by Nergal <nergal@owl.openwall.com> http://phrack.org/issues/58/4.html#article http://phrack.org/issues/58/4.html#article Think I actually looked at this and an (at the time) recent 0day for opensshd that was found and written up by a couple of Finnish students - as a motivational presentation for PaX and/or grsecurity while at university.
- saagarjha 6y ago
  Taken to the extreme, you have ROP: https://hovav.net/ucsd/dist/geometry.pdf https://hovav.net/ucsd/dist/geometry.pdf
hyper_reality 6y ago
Return Oriented Programming (ROP) can bypass the non-executable stack protection, since existing "gadgets" from program memory are executed rather than attacker-provided shellcode. However the stack protection will probably require a separate information leak (to find the canary value) or arbitrary write (to overwrite it) to bypass. Unless the attacker is fortunate to find an unprotected function which the compiler missed, or a value that can be overwritten which changes the control flow and isn't protected by the canary. ASLR is also a decent mitigation against ROP, and requires an information leak so the exploit code can calculate the memory offset to find the library gadgets. In short, ROP isn't the solution to all the mitigations the parent posted; in fact ASLR is designed to make ROP harder to exploit.
- saagarjha 6y ago
  And, if your hardware supports it, PAC and shadow stacks can help protect your return addresses too.
- wizzwizz4 6y ago
  > Unless the attacker is fortunate to find an unprotected function which the compiler missed, Every instance of the bytes C3, CB, C2 or CA in the executable page could potentially be abused, via carefully-chosen instruction alignment.

stevekemp 6y ago

Very much so. I wrote a couple of simple "exploiters" for particular bad-patterns I saw, shortly after reading this piece: https://steve.fi/security/exploits/ https://steve.fi/security/exploits/ These days these things are less useful, but recreating known-exploits is still educational. Once you get buffer-overflows handled you can look for more exotic things, format-string attacks, and similar.

e12e 6y ago
Oh, I didn't realize you were based in Finland - and only now realized why I've not seen any articles from the Deb adm site in a long while: http://web.archive.org/web/20190325214351/https://debian-administration.org/article/730/This_site_is_going_to_go_read-only http://web.archive.org/web/20190325214351/https://debian-adm... Without going too far side-tracked: I think the Arch wiki has demonstrated that a community wiki can be very useful - I do hope people continue to contribute to the Debian wiki (although I find myself mostly on Ubuntu of late). Anyway, there's a certain path from phrack through debian-administration.org that maps out where I find myself today, so happy coincidence to see the two line up in the threads.
- stevekemp 6y ago
  I moved from Edinburgh, Scotland, to Helsinki about five years ago. (I'm actually going to complete my post-Brexit registration to retain permanent residency this afternoon!) The arch wiki has been very useful to me over the past few years, I guess the barrier to entry there is lower for contributors. On my site I had a fair number of people writing interesting blog-posts, and comments, but only very very rarely did anybody submit an article. I felt like I had a good niche audience, but sadly never quite enough people to keep me really motivated. I'm just glad I managed to setup the redirects to the wayback machine - I feel like if the site disappeared for good I'd have lost a chunk of my life!

ahepp 6y ago

I'm trying to remember where, but I once saw this article presented with a very nice guide to replicating the exploits in a VM on a modern computer. I think it must have been in university, unfortunately when I look up the course number, the resources seem to be (understandably, I suppose) date gated.

navbaker 6y ago

I believe Hacking: The Art of Exploitation comes with a disc that has an exploitable image on it.