16 comments

[ 2.9 ms ] story [ 50.5 ms ] thread
I must be missing something. If you can create an executable which is suid you already have root...
The scenario is someone else has set setuid on an executable which is vulnerable to buffer overflows.
Why "echo 0 | dd of=foo" and not simply "echo 0 > foo"?

    echo 0 > foo //wont work with sudo ..
    sudo echo 0 > foo //will fail ... 
    sudo sh -c 'echo 0 > file' //If you want echo with sudo
else what author has done is right
piping to `sudo tee <fname>` is also a nice alternative
> ... -fno-stack-protector -z execstack

Does anyone know how common stack protector is in the wild?

Depends on which distributions patch gcc to enable it by default. From what I'm aware, a lot of them do, though.
Fedora 20 comes with fstack-protector-strong .. so does ubuntu arch openbsd/freebsd etc .
From the responses to this stackoverflow question: http://stackoverflow.com/questions/1629685/when-and-how-to-u...

The protection only protects under some circumstances not all. So this demo still seems valid. Also the protection comes at a cost of extra code (and extra execution time).

This means to me that any IoT device probably does not have stack protection.

Actually, this demo would be stopped if the stack protector was on. The demo relies upon overwriting the return pointer that controls where the function jumps to upon returning.

The stack protector acts as a guard against overwriting that value without knowing a key that is stored elsewhere in memory. You'd need some memory disclosure issue to get the key or brute force the key.

Almost every program nowadays is compiled with W^X (--no_execstack) by default which means the memory is not executable and writable at once (Windows equivalent is DEP). Still a good example of how a basic overflow can lead to arbitrary code execution. A follow-up post using ROP or return-to-libc would be interesting, with W^X enabled.
I'll try it next. Thanks for the suggestion :)