sorry to burst your security bubble, but things don't quite work the way you imagine it. the 2 byte overflow can very well lead to arbitrary code execution. imagine that the buffer you overflow ends just below the saved frame pointer (whether that actually occurs in real life binaries or not is a question you should have answered before jupming to conclusions about the bug being not exploitable). overwriting the 2 LSBs of the frame pointer with a fixed value of "k\0" will most likely decrease its value (on little-endian CPUs like i386), that is, on function return the frame pointer will point into a memory (stack) region that is not actually part of any live stack frame. depending on the execution history of the whole app (not only lib!) this memory region may very well be valid (mapped) already, hence further code executes with a frame (and later, stack) pointer that isn't quite where it's expected. since past execution may very well have left user controlled data on the stack where the code expects trusted data only, you have a situation wide open for exploitation. this isn't even something new, http://phrack.org/archives/55/P55-08 had desribed this a long time ago.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds