Contributed by jose on from the missing-information dept.
In particular it is quite sad to see how the author obviously is unaware of the article a few pages before (no PDF) on Adamantix which bemoans how quite a few programs do not run with PaX enabled under Linux, that PaX is not integrated by default in any distribution, etc. and compares it instead to OpenBSD where userland has been compiled with ProPolice and works with W^X and/or systrace.
I've written a letter to the editor as I happen to be a subscriber and I can demand that they leave out pointless trolling from the magazine but it would be good if someone from the OpenBSD camp offered to send them an article about "secure by default"."
(Comments are closed)
By Anonymous Coward () on
Just remember, when you do lodge your complaint with the editor present your facts clearly and plainly - you don't want to start a "my stack protection is better than yours" debate - that's just going to get messy :-)
Besides which: guess who had a XFree86 bug become a security problem recently and who just had a reliability hiccough...
Comments
By Anonymous Coward () on
Comments
By Anonymous Coward () on
By tedu () on
notable changes:
1. i deleted all chpax calls. i didn't feel like making it build when all it does is twiddle some bits we don't care about.
2. removed initial stack mprotect. no real applications do this, it just scews the result.
http://www.ussg.iu.edu/hypermail/linux/kernel/0312.2/1151.html
3. compiled with -fno-stack-protector, like adamantix. i used the adamantix makefile to start.
results, if they paste nicely.
PaXtest - Copyright(c) 2003 by Peter Busser
Released under the GNU Public Licence version 2 or later
Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable anonymous mapping (mprotect) : Vulnerable
Executable bss (mprotect) : Vulnerable
Executable data (mprotect) : Killed
Executable heap (mprotect) : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Killed
Executable stack (mprotect) : Vulnerable
Anonymous mapping randomisation test : 20 bits (guessed)
Heap randomisation test (ET_EXEC) : 5 bits (guessed)
Heap randomisation test (ET_DYN) : 5 bits (guessed)
Main executable randomisation (ET_EXEC) : No randomisation
Main executable randomisation (ET_DYN) : No randomisation
Shared library randomisation test : 16 bits (guessed)
Stack randomisation test (SEGMEXEC) : 15 bits (guessed)
Stack randomisation test (PAGEEXEC) : 15 bits (guessed)
Return to function (strcpy) : Return to function (strcpy, RANDEXEC) : Return to function (memcpy) : Vulnerable
Return to function (memcpy, RANDEXEC) : Vulnerable
Executable shared library bss : Killed
Executable shared library data : Killed
Writable text segments : Vulnerable
Comments
By djm () on
Writable text segments : Vulnerable
Huh? Shouldn't W^X prevent this? or are they doing more memprotect crap?
Comments
By tedu () on
in general, a lot of the tests are really tests of pax mprotect behavior, and not directly related to OS behavior with normal applications.
By Ulysses () on
is this good or bad?
Comments
By tedu () on
i'm running a pax free operation here, so i can't compare, but the test does indicate that w^x is doing what it's supposed to, killing programs that try to run modified code.
Comments
By Ulysses () on
:D
By netchan () deadly.org-NOSPAM@netchan.cotse.net on mailto:deadly.org-NOSPAM@netchan.cotse.net
netchan
Comments
By tedu () on
Comments
By netchan () on
netchan
By Peter Busser () peter@adamantix.org on www.adamantix.org
Comments
By tedu () on
mprotect will attempt best effort protection, but it will always work.
Comments
By Peter Busser () peter@adamantix.org on www.adamantix.org
I can understand why people do it like this, even though at the same time it means that if you can call mprotect() one way or another, you can also introduce an executable exploit payload. So this design decision introduces a weakness that you do not have to suffer with PaX (unless you choose to).
This is simply an area where PaX has an advantage. And there is nothing wrong with admitting that. It's not as if OpenBSD will ever look bad when people who use it admit that it is not perfect. You know, people already know that for a long time. :-)
Groetjes,
Peter Busser
By gwyllion () on
BTW users can specify the amount of stack randomization using sysctl kern.stackgap_random and the heap randomization only works when you have malloc_option G enabled.
Comments
By PaX Team () on
make that: OpenBSD is not designed to provide least privilege for memory protection. PaX is. i'd also stress 'privilege' - that's something that can be both taken and granted, OpenBSD (and other systems) grant this privilege without control whereas PaX lets you precisely control it. this control is a fundemental security feature, without it you cannot guarantee that an attacker is unable to execute his own code (for the glory detals read the PaX docs).
> So the only difference seems to be that PaX provides a bit more randomization.
you can't make that conclusion until you adapt the paxtest entropy measurement algo to OpenBSD, right now it's specific to the way PaX does randomization. e.g., the current algo overestimates the entropy coming from the OpenBSD random library order.
By gwyllion () on
it was about 5 minutes of work, most of which i spent finding the new pax website.
Indeed google doesn't know about the new pax website: pax.gresecurity.net instead of pageexec.virtualave.net
By PaX Team () pageexec at freemail.hu on mailto:pageexec at freemail.hu
http://marc.theaimsgroup.com/?t=106798300300001&r=1&w=2
the short story is that paxtest is a regression test suite, i.e., we want to know what fails, not what works. in this case 'what' refers to 'exploit techniques', so you should not take the OpenBSD failures so lightly, it points out exploitable weaknesses. for this reason removing the mprotect() calls from the tests gives you a false result as well ('no real applications do this' depends on what you call 'real', try a gcc nested function trampoline once, or if lazy, check out http://www.openbsd.org/cgi-bin/cvsweb/src/gnu/egcs/gcc/config/exec-stack.h then think about exploit techniques that can achieve the same).
PS: feel free to send your OpenBSD specific diffs to peter at adamantix.org, we'd like to incorporate them (last time this topic came up i asked gwyllion to do it but he never answered).
Comments
By tedu () on
do you have an example of a program that uses nested functions?
i read the debate with ingo before. as a regression test, paxtest is fine as is. but as a means of assessing protection, i think it makes more sense for a program to emulate sshd, apache, bind, ftpd, ..., none of which operate with an executable stack.
i'm not critical of paxtest. i'm critical of relying on its stock output to determine one's vulnerability to assorted exploits, when the test runs under conditions that are atypical.
Comments
By PaX Team () on
in any case, i think you're missing the same point that Ingo did as well. what you call atypical conditions are also the primary targets of exploit writers. your next question is then, how can an exploit writer create an executable stack (and under OpenBSD/i386, heap and everything) himself. there're different ways, from corrupting data that will cause an otherwise innocent mprotect() to do something bad to directly forcing an mprotect() call to achieve the same... the thing is, in OpenBSD you cannot say whether this is possible or not in any given bug situation so you're left guessing, or worse, assuming it's not possible. case in point, just look at the first post here where the author somewhat over-confidently suggests that the recent XFree86 bugs were not exploitable under OpenBSD - that's a completely unsubstantiated claim. to make you pause and think for a second consider the code where the bug occurs: it's a while loop parsing a file, to me it's not evident that you cannot create a multiple stack overwrite exploit (along with some info leaking maybe) that would circumvent ssp (propolice) as well.
By Peter Busser () peter@adamantix.org on www.adamantix.org
So whether something is typical or not is not relevant IMHO. The question is: Is it possible or not? If it is possible, it probably will be abused somehow at some time.
By PaX Team () on
Executable shared library data (mprotect): Killed
how do you explain the above? is it a bug somewhere (paxtest or OpenBSD) or a welcome feature (from my point of view anyway ;-)?
i'd like to note as well that the strcpy/memcpy tests in this paxtest version are somewhat broken with certain gcc versions (stack layout has changed a bit which the simulated payload doesn't account for), if you're interested in a fixed version, email me.
By Noryungi () n o r y u n g i @ y a h o o . c o m on mailto:n o r y u n g i @ y a h o o . c o m
I quickly read the article and OpenBSD ad W^X are mentioned maybe a couple of times and only to say that its performances were not as good as PaX.
What's the big fuss all about? Another programmer spouting nonsense about a competing project (that he probably knows very little about, btw). Just ignore him and he'll fade away like so many other religious freaks.
Comments
By grey () on
Brad Spengler on the other hand (GRSec developer) is much more outspoken and far less balanced in his perspective. He didn't write this piece however. That said, Theo's not exactly known for always debating things calmly and rationally. ;-)
By grey () on
Actually, I was rather pleased to see that the article focused primarily on PaX itself, and its own features. Times when OpenBSD were mentioned were actually relatively few, and really were just as critical of OpenWall or execshield in the same comparisons, if not even more so compared to the comments against OpenBSD.
He even mentioned, in his break down of his three percieved classes of attacks, that PaX currently only deals with one of them, even if plans are there for the other two - so it's obvious that it's not all roses in the PaX world either (showing his paxtest tool being run with several vunerable listings I guess is another way of showing that not all problems are yet addressed).
Naturally, no article is without faults, some may critique the author as discussing his own distro as biased (I think it's actually nice to see, and Theo has his W^X propolice slides from core03 out there as well), so that argument is moot. Comments like "the best memory protection available in the free software world" is a little more out there. To wit, Oded Horovitz's MAD (also presented at cansecwest last year) proof of concept code is free from what I recall, and excruciatingly more comprehensive than most other memory protection styles I've seen. Then again, MAD is to the point of being pretty much slow beyond use (2000:1 performance hit was it?) - perhaps exokernel OS's might be able to implement it effectively.
Probably the only real complaint I have with the author's comments in regard to OpenBSD, are with respect to his own paxtest software - the common scenario of wishing xyz feature would be implemented on zyx platform, but without taking the necessary steps yourself to do anything about it. This is particularly true in this case, where we have the author of the software in question, and he is the same one expressing the desire to see it run on OpenBSD - I can see no other person better qualified to make the port, so why doesn't he expend the effort? In the case of Felix's scalability tests, he himself made the efforts to get the code to run on all the platforms he tested, and did such effort before even reporting on his findings.
Nothing is perfect, but this piece was hardly a troll. I think one of the major breakdowns in both OpenBSD & PaX fanbase camps is the failure to see their own faults when they get into flame wars. This article, while mentioning faults of others, did not fail to point out its own; and similarly - most decent OpenBSD proponents I've met acknowledge the faults and limitations of OpenBSD. The real question, which I think is answered pretty much the same in both camps: is what is being done about the problems? I personally feel that the answer is that problems are dealt with, though the timing and prioritizing of their treatment might not always be to everyone's liking. Different projects have different focii and resources at their dispense.
Comments
By Anonymous Coward () on
Overall, I think it was a good article. Afterall, there is nothing wrong with a little competition.
By Anonymous Hero () on
One who looks with a critical eye to humanities' past easily recognizes apathy / the lack of self-criticism is a rather important reason of failure...
By Arrigo () on http://www.alchemistowl.org/arrigo
The article on Adamantix is a very well written description of what they are trying to achieve without leaving out any of their shortcomings, be it the fact that Java doesn't run out of the box (you need to turn off PaX protection) or that certain binaries simply won't run at the moment. Unlike the PaX article there is no attempt at claiming God status at all, in fact an excellent box on the differences between OpenBSD and Adamantix offers a very fair view and praises the BSD people for having a "coherent source tree from which everything is compiled".
While reading the PaX article the undertones of "I am a God oh you lowly peasant readers" and "PaX is the One True Answer" were what I felt ruined what would have otherwise been a very good article on the technology behind PaX. The little snide remarks on OpenBSD only added to it and frankly the bit about "someone should port paxtest" are a classic troll line. Not to mention the extra needless snipes at OpenWall which to its credit has been attempting to provide a more secure Linux distribution long before Adamantix was a glint in someone's eye.
Comments
By Peter Busser () peter@adamantix.org on www.adamantix.org
I bet that you don't like the Adamantix article anymore after I tell you that the author is also an Adamantix developer. See, I knew you wouldn't. :-)
Now I really start to wonder where that article is which lists all the OpenBSD shortcomings...
Groetjes,
Peter Busser
Comments
By ulysses () on
By Peter Busser () peter@adamantix.org on www.adamantix.org
With ``the best memory protection available in the free software world'', I meant memory protection which you can simply install and use. There are more research projects which increase the integrity of processes, but that doesn't help Joe User much, does it?
Paxtest was written because I did not trust the PaX author. He tells me that his patch does wonderful things. And then I start to run programs on a PaX kernel and they simply work. That doesn't make sense, I would have expected all kinds of problems. So I decided to write a test suite.
BTW, I am not the PaX author. He's Hungarian, I'm Dutch. Adamantix is just *using* PaX. I could switch over to exec-shield or OpenWall, if they provided more protection. So I am not dependent on PaX in any way. It is simply the best patch at the moment, and that is why Adamantix uses it.
The reason that PaX is not ported to OpenBSD is simply because noone asked the PaX author. The PaX author tried to educate some of the OpenBSD people about lacking functionality in the OpenBSD W^X implementation in the past, but noone was prepared to listen.
Groetjes,
Peter Busser
By netchan () deadly.org-NOSPAM@netchan.cotse.net on mailto:deadly.org-NOSPAM@netchan.cotse.net
By ViPER () viper@dmrt.net on http://www.dmrt.net
Comments
By Wijnand () on http://nedbsd.nl
By Peter Busser () peter@adamantix.org on www.adamantix.org
If what you guys say is true, that OpenBSD memory protection is indeed better than that of PaX, then why don't you simply prove it? Show me the facts!
Why don't you show paxtest results that are better than the ones run on an Adamantix kernel? Or better yet, write your own test suite and run that on Adamantix or any other PaX enabled system to show how well OpenBSD does compared to Adamantix. (BTW, I'm interested in a proper OpenBSD port of paxtest. And also in additional tests.)
The results of a quick paxtest port to OpenBSD (http://deadly.org/commentShow.php3?sid=20040216100029&pid=11) doesn't look very promissing. Compare that to the output of running paxtest on Adamantix (the output is printed in the PDF file of the article), and you know exactly what I mean.
Wether you like it or not, the article was simply stating facts. Too bad they don't agree with a few people's dogma. But that doesn't mean the facts are wrong...
Groetjes,
Peter Busser
Comments
By Anonymous Coward () on
By Anonymous Coward () on
With any luck, this post will be removed as well.