lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20040327112256.GA10031@devbox.adamantix.org> From: peter at devbox.adamantix.org (Peter Busser) Subject: Talk in #grsecurity Hi! > > Spender sent me the alleged exploit for exec-shield... and it bypasses the > > protections offered by exec-shield completely without the need for brute > > forcing. > Does it actually bypass a protection that exec-shield claims to give, or > is it doing something that exec-shield doesn't claim to be able to stop? I think we are talking about real bugs here. Exec-shield has had real bugs before. One of them was uncovered after a bug in PaXtest was fixed. (And I mean a real bug here, not the weaknesses in the exec-shield design.) There are other problems that some people know about. > There's no love lost between the pax and exec-shield crews: > > http://marc.theaimsgroup.com/?l=linux-kernel&m=107209069402935&w=2 > http://marc.theaimsgroup.com/?l=linux-kernel&m=107209256604442&w=2 > > So I'd evaluate very carefully any claim made by either crew. It's possible > that there is a real hole in exec-shield. It's also possible that the > "exploit" is simply doing stuff that exec-shield won't stop by design - > remember that a design *goal* of exec-shield was to not be as kernel-intrusive > as pax, so it would have a smaller footprint and be less likely to break stuff > unintentionally. If you start to evalute very carefully, you might as well take into account the motivation behind the things that people say. All PaX users and developers (I'm a PaX user myself BTW, not involved in development and never have been) I talk to do this stuff in their free time. That is, they do it for fun. There is no financial interest behind PaX. And its quality is what ``sells'' PaX. (That is also the reason why it is used in Adamantix. If there was something better than PaX, I would put that in Adamantix instead.) So far, my experience is that the people who are vocal about exec-shield are employed by one company. This company payed for the development of exec-shield and therefore has a direct financial interest in marketing their product. And this marketing made things dirty. Anyone who looks at the previous PaX vs. something else flamewars, will see that they typically started as a reaction of individuals in the PaX community against false claims and half-truths. What I hear from PaX users and developers in private conversations, is that most of them could not care less what other people use. They are happy with PaX and that is what counts. What they dislike however, is the never ending marketing crap where people claim that their patch is (almost) as good as PaX and that it has less problems than PaX. Personally, I dislike the way these anti-PaX people question my integrity and the integrity of PaXtest. PaXtest was used in the past to ``prove'' that exec-shield was (almost) as good as PaX. These people were happy with PaXtest and promoting it. In the meantime PaXtest has evolved to show the design decisions that result in security weaknesses in OpenBSD and exec-shield. Now everyone can easilly find out the truth about these products, they try to kill the messenger. First by telling people that I cannot be trusted (even though people who know me know that integrity is very important to me). And second by telling people that PaXtest is rigged and therefore cannot be trusted. Third by telling people to cripple PaXtest by removing the things that show the design decisions in their product. People aren't supposed to find about these weaknesses it seems. (BTW, I added comments in the code to facilitate these people.) You can configure PaX in such a way that it behaves much like exec-shield. But with equally lower security of course. So the compatibility issue between PaX and exec-shield is not as big as some people want us to believe. At least you can make your own choice between compatibility and security. The biggest advantage of exec-shield over PaX is that PaX halves the address space. Instead of the usual 3G address space, you get only 1.5G. So far I have never heard anyone complain about that, therefore I believe that it is not a big issue. For a number of corporate applications, I can understand why it is a big problem. I think that for applications like that, going 64 bit would be a more logical solution. BTW, this is a documented feature, just like all PaX features are documented (see: http://pax.grsecurity.net/docs/). The biggest advantages of PaX over exec-shield are that PaX supports many architectures. And it can provide perfect protection against ALL attacks where arbitrary code is injected and executed. No other kernel patch is able to provide a similar protection level. That's the truth. Groetjes, Peter Busser
Powered by blists - more mailing lists