[jsaxton86]

Consider the case of a buffer overrun, a vulnerability that can often cause segfaults. A clever attacker could write a bunch of nasty code to that buffer, then use the buffer overrun to insert a jump statement back to that malicious code. Maybe they added the equivalent "rm -rf $HOME`" or something. Or maybe they decided to dial home with a reverse shell on your system. You have no idea, since you have no control over what code is being executed.

[panzi]

How will they do this if it's a read buffer overflow, not a writer overflow?

[zxcdw]

A "read buffer" overflow is still nothing but a program reading some form of input and then overwriting the buffer. The target program has to read to somewhere -- namely to the buffer -- and thus it has to write over the boundaries of the buffer.

Because the buffer is local to the function, and because the function return address happens to reside at a higher address than the buffer itself, you probably get to overwrite the return address. Thus, after the function is executed, the execution doesn't return to the call-site but to the address you specified. Place your payload code in the buffer you provided, and overwrite the function return address to be the address of your buffer and you might do all sorts of fun things. Spawn a root shell (if suid binary), spawn a reverse shell, execute a kernel exploit to get root etc.

[panzi]

> A "read buffer" overflow is still nothing but a program reading some form of input and then overwriting the buffer. The target program has to read to somewhere -- namely to the buffer -- and thus it has to write over the boundaries of the buffer.

Who says that? That would be a write buffer overflow. The place where they write to might be properly allocated, so no memory that shouldn't be written is ever written. At least that is how I read it. The OpenSSL bug (heart bleed) was a read overflow. You couldn't use it to inject code, but you could use it to read out private keys.

[eli]

Because you control a bunch of memory around that buffer anyway. It's reading a file that you have complete control over, after all. The fact that it crashed at address "41414141" strongly suggests its exploitable. That value is like the "hello world" of testing vulnerabilities.

[panzi]

If something that shouldn't be written is written then yes. But from all the reports it sounds like it just reads something that shouldn't be read and produces a segmentation fault because it reads an unallocated page. I could be wrong about what happens, I haven't looked at it in detail. That is how the news reports sound like to me, so I wonder how could one use that to execute code?

[eli]

To quote the linked article: "The 0x41414141 pointer being read and written by the code comes directly from that proof-of-concept file and can be freely modified by the attacker to try overwriting program control structures."

[panzi]

I seem to have overlooked the "and written".