OpenBSD Journal

PaX and OpenBSD in Linux Magazine UK

Contributed by jose on from the missing-information dept.

Arrigo writes: "There is a rather unpleasant article (PDF) in Linux Magazine UK about PaX which is filled with digs against OpenBSD and how "inferior" its protection mechanisms are.

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)

  1. By Anonymous Coward () on

    mmm... that's a bit rude.

    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...

    1. By Anonymous Coward () on

      Wouldn't it be more useful if paxtest results for OpenBSD were made available?

      1. By Anonymous Coward () on

        'spose so... you offering?

      2. By tedu () on

        so other than a few linuxisms, the test runs pretty easily. it was about 5 minutes of work, most of which i spent finding the new pax website.

        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.
        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

        1. By djm () on

          Writable text segments : Vulnerable

          Huh? Shouldn't W^X prevent this? or are they doing more memprotect crap?

          1. By tedu () on

            mprotect first, then write to it.

            in general, a lot of the tests are really tests of pax mprotect behavior, and not directly related to OS behavior with normal applications.

        2. By Ulysses () on

          Could someone explain please?
          is this good or bad?

          1. By tedu () on

            what!?! we have to interpret results too?

            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.

            1. By Ulysses () on

              "what!?! we have to interpret results too?"


              1. By tedu () on

                look under src/regress

                1. By netchan () on

                  Got it, thanks.


          2. By Peter Busser () on

            The result is not as bad as the OpenWall patch. But not good either. On an Adamantix kernel, only the return to libc tests show Vulnerable.

            1. By tedu () on

              note that, regardless of your position on whether the top stack page mprotect is real application behavior or not, the result of other tests using mprotect, such as to enable exec bit on malloc regions, is a design choice of openbsd, and not going to change.

              mprotect will attempt best effort protection, but it will always work.

              1. By Peter Busser () on

                Fair enough. The exec-shield people do the same. And I think PaX can be configured to do something like that too.

                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. :-)

                Peter Busser

            2. By gwyllion () on

              OpenBSD is designed to allow mprotect, so it's logical that you see all these "vunerable"s instead of "killed". So the only difference seems to be that PaX provides a bit more randomization.

              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.

              1. By PaX Team () on

                > OpenBSD is designed to allow mprotect, so it's logical that you see all these "vunerable"s instead of "killed".

                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.

        3. 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: instead of

        4. By PaX Team () pageexec at on mailto:pageexec at

          to understand the whole idea behind paxtest and why the mprotect tests are relevant, see the thread here (a bit long but you can hopefully extract what's relevant):

          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 then think about exploit techniques that can achieve the same).

          PS: feel free to send your OpenBSD specific diffs to peter at, we'd like to incorporate them (last time this topic came up i asked gwyllion to do it but he never answered).

          1. By tedu () on

            "'no real applications do this' depends on what you call 'real', try a gcc nested function trampoline once, "

            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.

            1. By PaX Team () on

              if you mean a program under OpenBSD, then i have no idea as i never it (but you fixed your compiler for supporting trampolines under the new memory protection scheme so you must have run into real users). under linux there are at least two progams that install with glibc (localedef and another i forget right now) that use it, then there's an ALSA library that does (or rather, did, as we fixed it not long ago and it's now in upstream).

              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.

            2. By Peter Busser () on

              You can not know what is typical or not, because attackers do not obey any rules. You can only expect the worst and hope for the best.

              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.

        5. By PaX Team () on

          Executable data (mprotect) : Killed
          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.

  2. 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.

    1. By grey () on

      Agreed, no big fuss - note from the article introduction that Peter Busser was the author of the article, and is an admantix developer. He's also posted to deadly a bit in the past and is pretty lucid and balanced, IMO. Since you read the article quickly, you probably missed that, but he's not just another programmer spouting nonesense about things the doesn't know much about.

      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. ;-)

  3. By grey () on

    After that lead in, I went to read the article wondering just how much trolling would be present. I was expecting the worst given all the crap that pax/grsec/admantix/wideopenbsd/etc.etc.etc. crowd have left over deadly in the past on issues surrounding W^X and propolice in particular.

    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.

    1. By Anonymous Coward () on

      The only thing that really bothered me was saying pax randomization is better than that of OpenBSD randomization without providing any reasons for saying so, or even why he choose to single out OpenBSD as a comparrison. I also did not like the comment "I do not think that OpenBSD's W^X will return really convincing results". That's a little nicer than saying "it's better". Maybe he is just saying that to encourage someone to write the port?

      Overall, I think it was a good article. Afterall, there is nothing wrong with a little competition.

    2. By Anonymous Hero () on

      Good review of the review. Thanks!

      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...

    3. By Arrigo () on

      I would tend to disagree. If the article is read in conjunction with the previous one in the same issue (on Adamantix, sadly not available in PDF on the site yet) then the tone is glaringly different. In particular for Linux Magazine (UK) it is in stark contrast with the usual tone of the articles it contains which are professional and a at times a little "cold" if anything.

      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.

      1. By Peter Busser () on

        I didn't write a PaX article with undertones of ``I am a God oh you lowly peasant readers'' and ``PaX is the One True Answer''. The article is simply stating facts. So you must be reading things that are not there. But I think you are mistaking the article for the usual OpenBSD propaganda and the way you yourself normally treat people from other projects.

        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...

        Peter Busser

        1. By ulysses () on

          now your close to trolling...

    4. By Peter Busser () on

      Thank you grey, for this balanced review of my article.

      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.

      Peter Busser

  4. By netchan () on

    It's pretty sad, that the very bests of the area practically hates each other. There's a common aim, sometimes similar, sometimes different approaches. Everyone would win if there was a better relationship or maybe cooperation between the two groups.

  5. By ViPER () on

    I am one of the Crew admins of the dutch lan party outerbrains I'll make sure he gets the message :L

    1. By Wijnand () on

      See you there, let OpenBSD rule the party :-)

  6. By Peter Busser () on


    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 ( 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...

    Peter Busser

    1. By Anonymous Coward () on

      Arguements over the 'who has the best __' are so ridiculous, I'm not going to bother joining in (well...this time). I'm sure features and abilities will converge with time. I think what is far more important is to push for wider adoption of the techniques in question. Right now, OpenBSD and Adamantix (and any other PaX enabled systems) only make up a small number of the exposed machines out there (even if you only count Linux and BSD systems). Sure would be nice if the more (forgive this) mainstream operating systems would recognize the value of these techniques, and begin integrating them (instead of fussing over sexy but pointless new features). Trying to convince people to change operating systems (or even distributions of the same OS) just tend to be divisive and unhelpful. Perhaps getting operating systems to change will be more successful. Well, I can hope right?

  7. By Anonymous Coward () on

    I'd just like the record to show for archival purposes that after the Adamantix and PaX authors posed questions and brought up technical issues that the OpenBSD community could not refute, Jose threatened the Adamantix author privately and then disabled comments on the website for nearly a week. I wonder how OpenBSD progresses when they cannot even be "open" about their own software, and always have to be defensive when someone shows them that it's insufficient.

    With any luck, this post will be removed as well.


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]