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 :)

My favourite resource for these types of exploits used to be phiral.com (see Wayback Machine circa March 2007 [1], since it doesn't exist anymore), belonging to author Jon Erickson who wrote "Hacking: the Art of Exploitation" [2].

[1] https://web.archive.org/web/20070305111749/http://phiral.com...

[2] https://en.wikipedia.org/wiki/Hacking:_The_Art_of_Exploitati...

This book is quite good. It was my first introduction in this area.

The same author refers to another article of him, in which he explains the basics of buffer overflows quite nice. https://dhavalkapil.com/blogs/Buffer-Overflow-Exploit/

Here are 2 good courses on Assembly and Shellcoding on x86 and x86_64 if you are interested:

http://www.pentesteracademy.com/topics?v=nhr

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

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.

> ... -fno-stack-protector -z execstack

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

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.

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 .