Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Firstly, it's not exactly a novel problem - as the advisory points out, there were earlier public examples of the bug class in 2005 and 2010.

That aside, the issue here is that you can have a program that correctly writes only to properly allocated objects on the heap, and to properly allocated objects on that stack: but if you can get the stack to grow down into the heap without it being detected, now your properly-allocated objects on the heap alias part of the stack (and your properly-allocated objects on the stack alias part of the heap). So now the correct writes done by the program can write to unintended places, like return values on the stack or function pointers in the heap.

The core trick is the "without it being detected" part. What they've done is find places - some of them in library code - that the stack is grown by more than the size of the guard page in one go, and where writing to the guard page itself can be avoided (or in the BSD case, they've found ways that the guard page itself can be disabled). There's also some other clever tricks around expanding the stack and the heap.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: