"Exec Shield" for Linux: Linus is right
Posted May 3, 2003 7:50 UTC (Sat) by
john54 (guest, #10988)
In reply to:
"Exec Shield" for Linux: Linus is right by JoeBuck
Parent article:
"Exec Shield" for Linux
You are wrong. Lets take the big sendmail hole as an example, in which case a carefully constructed email header overflows a string buffer and a jump address located after the buffer. In the sendmail hole case, Linus' method works around any non-executable stack patch, but it does not work with the exec shield patch applied.
With the exec shield activated, as you can see in the original article, the system() function (part of libc) is placed into the "ASCII armor" area. So by overflowing the return address (or a function pointer, or anything else) with an _ASCII_ email header you simply cannot generate the proper return address that jumps on the system() function, because the address of the system() function contains the \0 [zero] byte. You can jump to any other address in virtual memory but the ASCII armor - exactly there are all the important shared libraries.
Even if 'by chance' there would be a lucky combination of bytes somewhere in virtual memory that could be used to get a shell, the exec shield does not allow those addresses to be executed.
So it's not just a matter of putting shared libraries into the ASCII-armor, but it's also the matter of restricting execution to _only_ this area. This is that makes this method so effective.
If the overflow is not ASCII-based, then it can be exploited in theory, as stated in the article as well. (most of the recent 'big' buffer-overflow holes were ASCII-based) But one thing is clear, the exec shield is much more than just a non-executable stack patch.
(
Log in to post comments)