11–17 of 17 posts
[1] https://web.archive.org/web/20070305111749/http://phiral.com...
[2] https://en.wikipedia.org/wiki/Hacking:_The_Art_of_Exploitati...
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.
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...
> ... -fno-stack-protector -z execstack Does anyone know how common stack protector is in the wild?
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.
> ... -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.
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.