[deleted]
Smashing the Stack for Fun and Profit (1996)
31–40 of 66 posts
Re: Smashing the Stack for Fun and Profit (1996)
#32A 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.
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.
> 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
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.
Re: Smashing the Stack for Fun and Profit (1996)
#33I think the main thing to discuss here is how, 25 yrs later, we're still getting overflow bugs.
It's a bit disappointing to still see overflows around, but at least blindly smashing the stack is no longer usually exploitable for modern systems with basic security.
Re: Smashing the Stack for Fun and Profit (1996)
#34A 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.
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.
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.
Re: Smashing the Stack for Fun and Profit (1996)
#35Earlier quoted context omitted.
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.
https://en.wikipedia.org/wiki/Return-oriented_programming I wonder if anyone's ever automated it.
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.
Re: Smashing the Stack for Fun and Profit (1996)
#36Earlier quoted context omitted.
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.
> 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 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…
Taken to the extreme, you have ROP: https://hovav.net/ucsd/dist/geometry.pdf
Re: Smashing the Stack for Fun and Profit (1996)
#37Earlier quoted context omitted.
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.
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 m…
And, if your hardware supports it, PAC and shadow stacks can help protect your return addresses too.
Re: Smashing the Stack for Fun and Profit (1996)
#38This has been required reading for all the pentesters at my org for the past 20 years.
This was required reading in my university's CS program.
Re: Smashing the Stack for Fun and Profit (1996)
#39A 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.
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/ 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.
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-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.
Re: Smashing the Stack for Fun and Profit (1996)
#40This has been required reading for all the pentesters at my org for the past 20 years.
Should propably be required reading for every programmer and especially for those that work with memory unsafe languages. With a side of modern mitigation techniques.[0] [0] https://en.m.wikipedia.org/wiki/Buffer_overflow (See buffer overflow protection)
A simple compare and contrast between C and zig/rust/D might be interesting - or even golang for that matter (the idea being that code could be reasonably similar, and yet somewhat idiomatic - and illustrate how the C code is exploitable, but the safe language version isn't - except when made to be).