| |||||||||||||
|
| |||||||||||||
"Exec Shield" for Linux: Linus is right"Exec Shield" for Linux: Linus is rightPosted May 2, 2003 22:51 UTC (Fri) by JoeBuck (subscriber, #2330)Parent article: "Exec Shield" for Linux
Since Linus has been so kind as to give everyone an easy-to-follow recipe (and I just checked to be sure that current glibc's have a "/bin/sh" string, they do), it seems that if a vendor wants to get any extra security by using this patch, the vendor will also need to purge all common shared libraries of any strings of that form. Unfortunately, it gets worse: assuming that /bin is on the path, all the bad guy needs is the three characters 's', 'h', and NUL, to appear in sequence somewhere in the binary or in some shared library to use the Torvalds attack, something that is a virtual certainty to occur just by chance. Now, it is true that the existing script kiddie exploits would break, but in about a month, we'd have a whole new set. So I've got to agree with Linus here.
(Log in to post comments)
"Exec Shield" for Linux: Linus is right Posted May 3, 2003 7:50 UTC (Sat) by john54 (guest, #10988) [Link] 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.
"Exec Shield" for Linux: Linus is right Posted May 4, 2003 22:19 UTC (Sun) by JoeBuck (subscriber, #2330) [Link] There have been bugs in image decoding libraries (PNG, JPEG) in which deliberately corrupt data causes a buffer overflow. In this case, the overflow data may contain NUL characters, so the ASCII armor trick will not work. You're also forgetting about locales that specify non-8-bit character sets. However, you are correct that tactics that just provide a long ASCII string to cause the overflow will not work.
|
|
||||||||||||