OpenBSD Journal

Randomization within malloc()

Contributed by jose on from the where-did-that-page-go? dept.

Tedu's gone and done it again, he's made some changes to malloc() that will help randomize the memory layouts:

Date: Wed, 8 Oct 2003 16:23:56 -0600 (MDT)
From: Ted Unangst


CVSROOT:        /cvs
Module name:    src
Changes by:     tedu@cvs.openbsd.org    2003/10/08 16:23:56

Modified files:
        sys/uvm        : uvm_map.c

Log message:
randomize return from uvm_map_hint.  the random increment is limited
to prevent fragmentation.
this has the effect of randomizing unhinted mmap()s, sysV mem, and
position of ld.so.

tested on many archs by many developers for quite some time.
use of MIN to allow m68k to play from miod@.
vax is not included.
ok deraadt@ miod@

The net effect of this is to make it harder for attackers to get the alignments of their exploits right, helping to increase the resilience of OpenBSD to common attacks.

(Comments are closed)


Comments
  1. By aisa () aisa@cybermesa.com on mailto:aisa@cybermesa.com

    I'm not sure I understand how this works. Does this randomize the virtual memory address that
    the allocation gets mapped into?

    It seems the code, instead of providing the "next" block of allocation, now gives any suitable block "near" the optimal allocation.

    My guess is that the space that is skipped by the randomizer remains unmapped by the process.

    Given that most programs don't come anywhere near using the entire address space, this seems like a super-keen thing to do, but I imagine it would reduce the useable address space for programs that might, like mmap'ing many large files.

    Please enlighten me...

    Comments
    1. By chuck () chuck@lemure.net on www.lemure.net

      From the description I follow it about as much as you. But from what it seems, the fragmentation would be minimal (haven't looked at code, spewing at random for the record).

      If your reading in a huge file thats going to use that much memory, your progam has bigger problems to worry about (IMHO). Thats what buffered readers in java are for, and similar mechnanisms in C.

      Normally also, using your example, I would guess that only the start and end of the block of memory would be randomized. So the entire block would still be contiguous.

      Comments
      1. By Anonymous Coward () on

        Hey, weird, I went to school (WPI) with you. What a small world. (We never met, but I recognize your name from mailing lists.)

    2. By tedu () on

      the "random" area is 256MB (for most archs). meaning each mmap can start anywhere within that space. but there's still a huge 2gb region that won't get splatted, so large files can be mapped.

      Comments
      1. By Anonymous Coward () on

        Nice. Thanks for the clarification.

  2. By asdfsfsdfsdfsdfsdfsdfsdfsdfsdfsdfsdfsdfsdfsdfsfsdf () on

    gone and done it again
    if "it" means copying yet another feature of PaX.
    way to go!

    Comments
    1. By Anonymous Coward () on

      I'm not familiar with PaX -- I'm guessing it is some kind of a security-addon 'also ran' that never quite made it into acceptance. If it has some good (non-obvious) ideas worth emulating, why not reimplement them?? That is a lot better than letting them die in obscurity in a system that will never see widespread use!

    2. By tedu () on

      except pax doesn't do anonymous mmaps, which are kinda important.
      nevermind that it's a _one_ line change. clearing something that required changing a whole one line of code is so complex that only the super geniuses at pax could have developed it.

      Comments
      1. By Anonymous Coward () on

        wrong. where do you get your information from? Theo? That would explain it.

        Comments
        1. By Anonymous Coward () on

          he's the developer who did it, troll.

          now go away, troll.

      2. By tedu () on

        err, nevermind. read that wrong. PaX doesn't disregard the hint sometimes. my mistake.

    3. By Anonymous Coward () on

      The PaX troll(s) keep speaking of OpenBSD implementing things that "PaX" did as if it's a BAD thing. I don't get it. To me, the fact that OpenBSD developers actually look at what ideas are out there for how to improve security and go take the ones they like and put them into OpenBSD is a very GOOD thing.

  3. By tedu () on

    just mmap, not malloc. that part hasn't been committed yet. :)

  4. By Xcom () on

    What is the speed impact on this? If a program allocates large chunks of dynamic memory, wouldn't there be a significant speed impact when reading from memory? Just wondering :)

    Comments
    1. By Fábio Olivé Leite () on

      Once the memory is mapped there´s no speed impact whatsoever to access it, it´s just as without randomization. The only possible impact would be the added instructions to add a random delta to the base address when you map it.

  5. By Anonymous Coward () on

    tedu claims in this thread:

    "except pax doesn't do anonymous mmaps, which are kinda important."

    Maybe you missed this part, when you were reading the PaX documentation to see what you could copy next and gain some fame for:
    http://pageexec.virtualave.net/docs/randmmap.txt

    The goal of RANDMMAP is to introduce randomness into memory regions handled
    by the do_mmap() kernel interface. This includes all file and anonymous
    mappings, such as the main executable, libraries, the brk() and mmap()
    managed heaps.

    please apologize for your malicious lie. thank you.

    Comments
    1. By Anonymous Coward () on

      go away, troll

    2. By gwyllion () on

      Why do you trolls keep claiming OpenBSD just is copying PaX features? This again proves that OpenBSD developers don't give a fuck what features PaX provides! They just don't look at PaX (not at their source, nor at their documentation)! They come up with these features themselves. Why do you trolls keep having a hard time believing this?!

      Have a nice day.

      Comments
      1. By Anonymous Coward () on

        Perhaps because never in the history of OpenBSD have they ever developed anything that was not done before? Maybe because features in PaX show up weeks later in OpenBSD? Maybe because I've heard first-hand reports of people who have discussed PaX with OpenBSD developers 2 years ago, when Theo still claims he had never heard of PaX? Maybe because I've seen access logs from OpenBSD developers to the PaX documentation? I know you are liars. It's incredible that you people have no integrity.

        Comments
        1. By Michael () on

          Proof? I'm not calling you a liar, it just that you are either telling the full, honest truth or you are blowing steam. Without proof, I have no idea what to believe.

          If you are correct, I'd like to know about it.

        2. By tedu () on

          the first i heard about PaX was after W^X was committed. of course, i had nothing to do with writing W^X. after that, i read the docs. when did i say i didn't read it?

          calling people liars when they haven't told a lie isn't very nice.

        3. By gwyllion () on

          Perhaps because never in the history of OpenBSD have they ever developed anything that was not done before? Oh, yes of course. Since OpenBSD was started, they never developed anything new, they never found a single bug in the audit process, they never wrote any new code, ... Yes, of course. Maybe because features in PaX show up weeks later in OpenBSD? Maybe because I've heard first-hand reports of people who have discussed PaX with OpenBSD developers 2 years ago, when Theo still claims he had never heard of PaX? Sorry, you've claimed this numerous times. Please name these OpenBSD developers. In the past (in other discussions) you never succeeded it given proof of this claim. See href=http://marc.theaimsgroup.com/?l=bugtraq&m=106124438821224&w=2 and href=http://marc.theaimsgroup.com/?l=bugtraq&m=106132585529503&w=2 A great quote by miod >Maybe because I've seen access logs from OpenBSD developers to the PaX documentation? Do you authentic logs of OpenBSD developers reading the PaX documentation before they implemented W^X and you started bitching on misc@? Please show them. I know you are liars. It's incredible that you people have no integrity. And posting messages as an Anonymous Coward proves your integrity? Smells like pure troll to me.

          Comments
          1. By gwyllion () on

            Sorry for the fucked up html.

        4. By gwyllion () on

          Perhaps because never in the history of OpenBSD have they ever developed anything that was not done before?

          Oh, yes of course. Since OpenBSD was started, they never developed anything new, they never found a single bug in the audit process, they never wrote any new code, ... Yes, of course.

          Maybe because features in PaX show up weeks later in OpenBSD? Maybe because I've heard first-hand reports of people who have discussed PaX with OpenBSD developers 2 years ago, when Theo still claims he had never heard of PaX?

          Sorry, you've claimed this numerous times. Please name these OpenBSD developers. In the past (in other discussions) you never succeeded it given proof of this claim. See href=http://marc.theaimsgroup.com/?l=bugtraq&m=106124438821224&w=2 and href=http://marc.theaimsgroup.com/?l=bugtraq&m=106132585529503&w=2 A great quote by miod "more exactly, we heard of pax when they started bitching".

          Maybe because I've seen access logs from OpenBSD developers to the PaX documentation?

          Do you authentic logs of OpenBSD developers reading the PaX documentation before they implemented W^X and you started bitching on misc@? Please show them.

          I know you are liars. It's incredible that you people have no integrity.

          And posting messages as an Anonymous Coward proves your integrity? Smells like pure troll to me.

          Comments
          1. By Anonymous Coward () on

            "Oh, yes of course. Since OpenBSD was started, they never developed anything new, they never found a single bug in the audit process, they never wrote any new code, ... Yes, of course."

            A 12 year old can find bugs in code. This is nothing *new*. They're just repackagers of others' ideas and code. I've not yet seen any valid refutation of this.

            Comments
            1. By Anonymous Coward () on

              What about pf...

      2. By Anonymous Coward () on

        did you see tedu admit that he has read the PaX documentation? (with the qualifier that he never said he didn't look at the documentation, pure genius) I guess you were wrong. Now please shut up you ignorant OpenBSD asshole.

        Comments
        1. By gwyllion () on

          did you see tedu admit that he has read the PaX documentation?

          Yes.

          I guess you were wrong.

          Yes.

          Now please shut up you ignorant OpenBSD asshole.

          No, thank you.

      3. By Stripes () dsbnepo.20.stripes@antichef.com on mailto:dsbnepo.20.stripes@antichef.com

        They just don't look at PaX (not at their source, nor at their documentation)!

        Well that seems kind of silly. If PaX has had good ideas in the past (like this one) then it is dumb not to pick it over to see if there is anything else good to borrow.

        After all, which is the better open source motto: "If I have seen farther then others it is because I have stood on the shoulders of giants", or "If I have seen no farther then others it is because I have stood in the footsteps of giants"??

        There is no shame in recognizing the good ideas of others. There is some in ignoring them.

        Comments
        1. By Anonymous Coward () on

          Of course, but if you are taking ideas from others, it is proper to CREDIT them for those ideas. Otherwise people assume you are the originator of the ideas that resulted in your implementation.

          OPENBSD IS LYING TO ITS COMMUNITY ABOUT THIS. STOP MAKING EXCUSES. THEO IS A FRAUD.

          Comments
          1. By Ulysses () on

            you seem to have issues..

    3. By tedu () on

      i was referring to "(unfortunately there is a 'feature' in linuxthreads where the thread stack mappings do not specify
      MAP_FIXED but still expect that behaviour so the hint cannot be overriden for anonymous mappings)".

      sorry, it's been a while since i read that page and i misinterpreted it. now instead of being such an ass, why couldn't you have just said "hey, that only applies to mappings with a hint"?

      for the record, openbsd doesn't tinker with mmaps that have a hint provided, only NULL hints.

      Comments
      1. By Anonymous Coward () on

        So in summary, you were wrong. Why couldn't I have just said "hey, that only applies to mappings with a hint"? Because given OpenBSD stance towards other projects that they take ideas from (take the ideas behind closed doors under the protection of private mailing lists, and then bash the projects in public) I don't feel that you or any other OpenBSD developer deserves my respect, and so you will be treated in a manner reflective of how you treat others. Such a quick change for you when just a thread up you were making sarcastic remarks about the ability of the PaX team. Perhaps you should take some of your own advice.

        Comments
        1. By tedu () on

          show me one sarcastic remark i have made about pax in this thread.

          Comments
          1. By tedu () on

            ah, i see what you're talking about. i called you a super genius. keep in mind, it's only sarcastic if it's not true.

            Comments
            1. By Anonymous Coward () on

              I am not involved with PaX, so don't direct your comment at me.

        2. By Anonymous Coward () on

          You know, the funny thing about your comment is that you started by belittleing everything tedu's intellegence and the things he does in his spare time, then instead of trying to have a civil conversation about the merits of both sides of the argument, you act like a bratty 6 year old who had his GI Joes taken away and then you get mad when tedu gets tired of your attitude, and decides to give you some back? Grow up.

          Comments
          1. By Anonymous Coward () on

            Hi.

            Learn how to spell.

            You know, the funny thing about your comment is that I don't give a fuck about what some idiot who doesn't know how to spell has to say about me.

        3. By krh () on

          > I don't feel that you or any other OpenBSD developer deserves my respect, and so you will be treated in a manner reflective of how you treat others.

          When I read this, I can't help but think you're a jerk. Sorry, that's just how I feel.

          Comments
          1. By Anonymous Coward () on

            When I read this, I can't help but think I don't care what you think. Sorry, that's just how I feel.

  6. By Anonymous Coward () on

    Here's a question for the openbsd developers who were involved in the randomization "development" on OpenBSD.

    Do you know how infoleak bugs are exploited?

    Do you know your between-mapping randomization is a waste of code?

    Do you realize that by modifying the mmap base, all subsequent mappings are randomized (yes, including anonymous mappings tedu, you retard)?

    Why do you make a big deal out of your between-mapping randomization when it serves no purpose? Is it simply to make yourself look like less of a rip-off from PaX by copying the features that actually do things (I noticed you used the same 16-bit mmap base randomization PaX uses) and then adding useless bloat?

    Very interested in your response, geniuses!

    Comments
    1. By ulysses () on

      you actually expect a respons when you call people retards? Or are you, like so many others, just trolling? With that tone anyone reading it would say 'oh another troll', and just ignore you, without considering if you might have a point or not. you dont score points by insulting people.

    2. By gwyllion () on

      Please use the official tech@ mailing list to ask technical questions. Almost none of the OpenBSD developers read this website.

    3. By Iain K. () on mailto:ikyte(at)yahoo(dot)com

      I really do not see how this creates more security. Please give a senario of how this will secure the os and other porcesses.

      I think just locking the memory according to type is the key.
      Kernel code - read only unmodifiable but executable
      Kernel scrach pad -- Read/Write non-executable
      Kernel Stack -- Read/Write non-executable
      Procees Code -- Read Only executable
      Process Heap -- Read/Write non-executable
      Process Stack -- Read/Write non-executalbe

      Best for Applications code is to put some padding to the page boundry so it can not be used as part of the Heap or Stack.

      Next process is to have applications with out terminals. In particular remote terminals. If the application fails the connection is broken and request for authentication will be required to re-establish connection.

      Other area is in setting up quick privalege upgrading algorithums and analysis of the the procedures to death. Idea is that you should have the preperation stage, change to the higher level, execute the privaleged task, drop back to the lower level. Area to examine is to have a timed privalege window. This is the area to do a good amount of research on.

      For this random allocation idea, it does not make sense. If I am going to put my egg into the system I do not care where it happens to fall but that I can point to it. It does make it so I can not use hard links but relative links. Since the idea of hard coded moves, jumbs and subroutines have left with moddern compilers and linkers, I do not see this being used.

      Please could you in favour for Random Memory Allocation Protection Method show some research papers on this sumbject for the community?

      Iain

    4. By tedu () on

      sigh, i read the page wrong. get over it.

      what the hell does "between-mapping randomization" mean? each mapping has a random start? yes, that's approximately what we are doing. are you only creating one gap and then mapping linearly after that? that sucks.

      it happens to be 16 bits on i386. 256MB is a reasonable amount of VM space to burn on fragmentation, while avoiding frequent collisions. i mean really, there's only so many values that make sense. maybe we should have picked 24 bits and completely burned out the VM? is that your suggestion? maybe you'd care to explain what scientific principles you used to determine that 16 bits is the perfect amount?

      what "useless bloat" are you talking about? it's one line of code. i suppose i could have rolled it into the return, making it half a line, but expending a whole line was considered acceptable bloat in this case.

      finally, who the hell is making a "big deal" about this? i made a commit, it got mentioned on deadly. did you see me running around shouting "openbsd roxors"? does the commit message exagerate the facts?

      Comments
      1. By Anonymous Coward () on

        "what the hell does "between-mapping randomization" mean? each mapping has a random start? yes, that's approximately what we are doing. are you only creating one gap and then mapping linearly after that? that sucks."

        You completely sidestepped the issue that I presented in my comment. I questioned the usefulness of your procedure of putting a random gap between each mapping (randomizing their order, which went in a while ago, also falls into this). These "ideas" smell like you have no idea what you're doing or what you're even trying to protect against. It is clear to me that these features are useless when you already randomize the mmap base. My post was intended to have you tell me why you have implemented these features. Surely you should have some legitimate reason.

        Comments
        1. By tedu () on

          randomized base:
          |--random gap--||-- mapping A --||--mapping B--|

          what happens when an attacker overflows A? he hits B. so if you know that writing 172 bytes past A will corrupt B in such a way as to lead to an exploit, no amount of adjusting the base helps.

          openbsd random mmap:

          |-- mapping A --||-- some random space --||-- mapping B --|
          or
          |-- mapping B --||-- random gap --||--mapping A --|

          now, if you overwrite A, you hit unmapped space and die. in fact, B may even come before A. given the hypothetical attack above, this is precisely what i'm trying to prevent.

          it's possible for mapping B to come precisely after mapping A, but unlikely. just in case, it would be better to see guard pages, guaranteeing empty VM between mappings.
          you can get a patch for this from
          http://www.zeitbombe.org/openbsd.html

          does that adequately not sidestep the issue? how does PaX prevent overflowing A from overwriting data in mapping B?

          Comments
          1. By Anonymous Coward () on

            That's the stupidest answer I've ever seen. So you think it's a security risk that someone who can overwrite at the end of a library can write into the next? Did you forget that the next mapping begins with a r-x segment, which you can't write into? So I ask again, WHY do you think this trash is useful?

            Comments
            1. By tedu () on

              have you ever heard of an anonymous mapping? an anonymous mapping which is read/write? have you considered that we might be trying to switch to mmap-based malloc? have you considered that the sshd "exploit" last week wouldn't have been anything at all if there was a guaranteed unmapped page after the allocation?

              Comments
              1. By Anonymous Coward () on

                so how to you plan to keep performance while keeping track of 100,000 mappings in your VM for a process that under the old brk() heap would have no problem? Since to "guarantee" anything, you would need one of these gaps between each allocation. What about programs that handle their memory allocation (allocating large chunks and then distributing them among callers in smaller chunks)?

                You can't guarantee anything.

                Comments
                1. By tedu () on

                  that's what makes it interesting.

                  Comments
                  1. By Anonymous Coward () on

                    so malloc will waste 2 pages of memory then?

            2. By tedu () on

              let me ask another question. why does PaX randomize all mmaps if only library mappings can be exploited (as your post suggests)?

              Comments
              1. By Anonymous Coward () on

                it's the entire point of full address space layout randomization. If there is not a single instance where an attacker can place data at a known location, he will have a much harder time trying to launch a successful exploit. Your question is stupid.

                Comments
                1. By tedu () on

                  relative addressing?

                  Comments
                  1. By Anonymous Coward () on

                    How is relative addressing an issue in PaX when there is no arbitrary code execution?

                    How does this have any application to 95% of OpenBSD users either? It's just a silly, useless feature.

        2. By tedu () on

          btw, randomizing load order indirectly leads to random addresses. sshd loads 8 libraries. 8! is 40000, meaning if you have some return to libc attack, libc could be at one of many many different locations.

          in short:
          attack type: return to libc.
          solution: move libc.

          Comments
          1. By Anonymous Coward () on

            That's a stupid example to give. It assumes that what the attacker needs is in one library only. The truth is that you can most likely use any of the libraries that are mapped, and thus you only have 8 choices to attack the first library. Your math is silly. This also provides no greater protection over randomized mmap base. If you can see the adresses via an infoleak bug, it doesn't matter if you randomized the load order of the libraries.

            Comments
            1. By Anonymous Coward () on

              If you can see the adresses via an infoleak bug, it doesn't matter if you randomized the load order of the libraries.

              Sorry, OpenBSD doesn't provide proc/pid/maps and /proc/pid/stat like PaX.

              Comments
              1. By Anonymous Coward () on

                Hi genius, format string vulnerabilities can cause infoleaks of the address space. Please think before you type.

                Comments
                1. By tedu () on

                  maybe the application your attacking doesn't have any bad format strings?

                  Comments
                  1. By Anonymous Coward () on

                    format strings aren't the only bug that can cause infoleaks.

                    Comments
                    1. By Anonymous Coward () on

                      exactly!
                      Now piss off, troll.

              2. By gwyllion () on

                Damn, more Anonymous Cowards using anonymizer.com, now things become confusing.

              3. By Anonymous Coward () on

                Hi genius, format string vulnerabilities can cause infoleaks of the address space. Please think before you type.

      2. By Anonymous Coward () on

        btw, the comment about bloat did not say code bloat. What I meant was feature bloat. There have been several added features involving randomization lately, and all of them but the randomized based (which PaX does) are useless. Of course, when you don't have any documentation on it and leave your users in the dark, it's easy for them to think it's actually useful. I can't count how many times I've seen the media make OpenBSD look like it's so much better than it really is. Things like "built from the ground up for security" or "if you care about security, OpenBSD is the only choice." These kinds of lies propagate because of your leading wording. The PaX team clearly states what their modifications will *not* protect against. Why have you not ever done that, unless it's for the reason of keeping your users in the dark about what they're using and gaining more undeserved fame for yourself?

        Comments
        1. By tedu () on

          only randomizing the base does not protect against what i'll call an "inter mapping overrun". overruning one piece of memory to attack a second. if you don't separate the two parts of memory, their relative locations remain the same.

  7. By atone () repent@the.net.nz on mailto:repent@the.net.nz

    hey, is there a simple mechanism in order to disable all and any performance-reducing security-increasing mechanisms for low-risk lower-cpu machines? i know there's likely to be some kind of sysctl things, but i was wondering if there's a guide on how to disable everything.

    Comments
    1. By Anonymous Coward () on

      Use the source, Luke.

    2. By Sam () on

      Yes. Install something else.

  8. By Anonymous Coward () on

    The only problems I've ever seen have been from pax trolls, so why not just disable comments on stories that have anything to do with anything pax does?

    Comments
    1. By Anonymous Coward () on

      or how about: start giving credit for ideas you've taken from their documentation, or stop taking them at all. tedu admits he's read their documentation. how can he claim ignorant independent development of these features now? Why is he and the rest of the OpenBSD developers exempt from doing the right thing and giving credit where credit is due?

      Comments
      1. By gwyllion () on

        Sorry, but it looks to me that they are implemented what Theo described in CanSecWest 03 presentation as future work.

        Future work

        Randomized mapping for shared objects
        Try to find a way to map the main program randomly (ELF does not do so)
        Randomized mmap
        malloc & mmap that fragment slightly -> insert guard pages
        guard pages in the data segment?
        link all non-buffer objects near start of data segment, BEFORE buffers?

        The malloc guard pages (implemented by tedu) are still in testing I've heard. By the way can you point me to the relevant PaX documentation on this future feature (malloc guard pages)?

        Comments
        1. By Anonymous Coward () on

          and you don't find it funny that everything listed in the "future work" section is just features of PaX and other people's work? Also funny that right below these "new ideas" is a remark about PaX. I'm sure it's just a coincidence.

      2. By Anonymous Coward () on

        note that i'm not asking for them to say every time they take one of the ideas that they got it from PaX, but it would be nice to see at least ONCE somewhere on the website or on their mailing list that that is where the ideas are coming from, because it's clear to anyone with a clue.

        Comments
        1. By gwyllion () on

          note that i'm not asking for them to say every time they take one of the ideas that they got it from PaX, but it would be nice to see at least ONCE somewhere on the website or on their mailing list that that is where the ideas are coming from, because it's clear to anyone with a clue Do you actually believe they will every give any credit to PaX after being called retards, liars, ..., after being harassed on mailing list and website, ...? Some PaX fanatic even threatened to release a local root exploit for systrace, in his cry for attention. If this happened to me, I would personally never provide credit, ever.

          Comments
          1. By gwyllion () on

            Sorry, I keep messing up html.

        2. By gwyllion () on

          note that i'm not asking for them to say every time they take one of the ideas that they got it from PaX, but it would be nice to see at least ONCE somewhere on the website or on their mailing list that that is where the ideas are coming from, because it's clear to anyone with a clue

          Do you actually believe they will every give any credit to PaX after being called retards, liars, ..., after being harassed on mailing list and website, ...? Some PaX fanatic even threatened to release a local root exploit for systrace, in his cry for attention. If this happened to me, I would personally never provide credit, ever.

          Comments
          1. By Anonymous Coward () on

            Why do PaX "fanatics" have to do with OpenBSD giving credit to PaX? These "fanatics" have nothing to do with the developers, so why do you think OpenBSD is exempt from doing the right thing because of this? Calling people retards, liars, harrassment...is this not what OpenBSD does themselves? check misc@ or bugtraq if you need examples. Get your head out of Theo's ass and maybe you can think more clearly.

          2. By Anonymous Coward () on

            btw, about the systrace exploit: someone on IRC sent me this md5sum of what he claimed to be the systrace exploit:

            b80d342b4f2e241d5a495e77360194ee

            I suppose in a few years (if the bug is ever found and fixed) we'll find out if it's true, and if it is, won't you feel stupid knowing you've been owned for that long?

            Comments
            1. By Anonymous Coward () on

              this is an md5sum of my old PaX exploit. it still works with the latest release

              73a5d5ea1c309a41d3f1b23ee78cd01

      3. By gwyllion () on

        How can he claim ignorant independent development of these features now? Why is he and the rest of the OpenBSD developers exempt from doing the right thing and giving credit where credit is due?

        Why do you keep begging for credit? Isn't it time to start harassing someone else? Perhaps Ingo Molnar. In the description of Exec Shield he doesn't give credit to PaX (nor to OpenBSD)

        By the way can you explain the difference between Exec Shield, OpenBSD and Windows non-exec pages implementations? The PaX website describes them as:
        the first independent Windows NT/2000/XP implementation by SecureWave
        the second independent Windows NT/2000/XP implementation by Data Security Software
        PaX features are part of OpenBSD
        non-executable stack and heap pages based on the segmentation logic implemented in Exec Shield (this description is hopelessly out-dated as it implements complete randomization of the whole address space as well)

        So of all these projects only OpenBSD blindly copied PaX and the others didn't? These Windows implementations of the PaX ideas are independent and when OpenBSD claims they developed this independantly, you keep bitching on mailing lists and websites. Grow up!

        Comments
        1. By Anonymous Coward () on

          He doesn't need to give any credit to OpenBSD. He does need to give credit to PaX because he has talked directly with the developers, which resulted in the randomization features that were added later. Execshield has nothing to do with OpenBSD, so why would I be talking about them here?

          BTW, you're reading that page wrong. It means that PaX uses the segmentation feature of the intel architecture to implement non-executable pages, and notes that the same thing is done in other projects (though their implementations are less effective to varying degress).

        2. By Anonymous Coward () on

          also, I think Ingo did give credit to PaX at some point. I remember him saying something to the effect of execshield being like PaX without the more controversial features.

          As for the difference between the various implementations:

          Exec shield is even worse than W|X. It doesn't even guarantee that when a process is loaded, unless it specified to map something writable and executable, that no page will be both writable and executable. The randomization features are similar to PaX's (since it was taken from PaX)
          It is also i386 only.

          W|X is inferior to PaX because it cannot guarantee the inability to execute arbitrary code. PaX can do this. PaX supports more architectures than W|X: i386 (a per-page implementation, which Theo claimed to be impossible), alpha, parisc, ppc (with a per-page implementation, which Theo also claimed to be impossible), sparc, sparc64, amd64, and ia-64.
          PaX has larger randomization than W|X as well. PaX has non-executable and read-only kernel pages, W|X does not (though they are going to copy this too eventually).

          The windows non-exec implementation was developed by one of the original PaX developers, so it used the old PAGEEXEC method. I don't know much about it other than that.

          Also, this comment:
          "(this description is hopelessly out-dated as it implements complete randomization of the whole address space as well)"
          is completely irrelevant to what you were referring to and shows your complete lack of knowledge on the subject.

          Comments
          1. By Anonymous Coward () on

            I also know nothing about the second, newer Windows implementation.

            Comments
            1. By Anonymous Coward () on

              Also, though the *implementation* is independent, it does not mean that the development of the ideas were independent. The implementation being independent only means that it was not done by the PaX team themselves.

          2. By gwyllion () on

            PaX supports more architectures than W|X

            Wow, I didn't know Linux supported more architectures than OpenBSD. Do you expect W^X to work on amd64 and ia-64, two platform which OpenBSD isn't ported to yet? These architecture have hardware support for non-executable pages, so adding support isn't that difficult.

            i386 (a per-page implementation, which Theo claimed to be impossible), alpha, parisc, ppc (with a per-page implementation, which Theo also claimed to be impossible), sparc, sparc64, amd64, and ia-64.

            Sorry, but where did Theo claim this was impossible. I can only find emails in which he says they thought it was impossible. Read this email on bugtraq ; "If we had been aware of PAX as you claim, why would we have thought that i386 solutions were impossible?"

            Also, this comment: "(this description is hopelessly out-dated as it implements complete randomization of the whole address space as well)" is completely irrelevant to what you were referring to and shows your complete lack of knowledge on the subject.

            Sorry, but I thought PaX people were making a distinction between non-exec stack+heap and PaX features (non-exec pages + address space layout randomization). I think Exec Shield and OpenBSD fall under the same category.

            BTW Theo invites PaX people at his talk at pacsec.jp :-)

            Comments
            1. By Anonymous Coward () on

              That's humorous. While Theo is busy blowing off hot air (nothing new there), noir will be releasing exploits for undisclosed holes in OpenBSD at G-Con.

              Theo is of course welcome. Other talks will include how to bypass W^X, and how non-executable pages are possible on MIPS (contrary to what Theo claims).

              Some arms race Theo: you can't have an arms race with stolen goods.

              Comments
              1. By Anonymous Coward () on

                > noir will be releasing exploits for undisclosed
                > holes in OpenBSD at G-Con.

                Oooohh I sooo scaaared. Mommy, mommy where are you?!?

                Release the ooohh sooo evil OpenBSD exploit. Show it, c'mon, let's see it.

                Mmmm hmm, it either it does exist and you'll actually be right about something for once in your life (and we'll gladly fix it) or it doesn't exist.

                But it doesn't exist, does it. No. No one will ever see it. Oh they'll talk about it. Just like people talk about PaX exploits all the time. But you never see them.

                > Some arms race Theo: you can't have an arms
                > race with stolen goods.

                Yet you still try.

                Comments
                1. By Anonymous Coward () on

                  Hello Theo.

                2. By Anonymous Coward () on

                  > Yet you still try.

                  I'm sorry Theo, I think you have that backwards. Did you forget you're just copying work that has been available for years? How's it feel to not be "#1 in the industry for security"?

                  PaX can stand on its technical merit.
                  You have to rely on your immature personal attacks that in the end make you look like an asshole.

                  How does making false, ignorant statements about another project change the effectiveness of its code?

                  You've already lost, Theo. Give up.
                  It's clear that you never have anything of technical importance to contribute, and when you try, you're wrong, so please, just stop.

          3. By tedu () on

            "W|X is inferior to PaX because it cannot guarantee the inability to execute arbitrary code. PaX can do this."

            you can only do this if you disable mprotect. that's not an option.

            the per-page ness was a lot more complicated than W^X. you can get pretty close using just the hardware without having to reimplement stuff in software.

            Comments
            1. By Anonymous Coward () on

              wrong again. read mprotect.txt. The segmentation-based implementation of PaX provides per-page non-executable pages. I was not referring to the old PAGEEXEC feature which is not used anymore. SEGMEXEC has no performance hit, and PaX didn't have to rewrite any of userspace to do it. Shows you what can be done with a brain instead of having a room full of OpenBSD monkeys hammer away at a problem with stupid implementations until it works.

              Comments
              1. By tedu () on

                and now there's only half an address space.

                Comments
                1. By Anonymous Coward () on

                  This has never been a problem, and if needed, it can be easily changed. It can be toggled on/off on individual binaries as well. I know you're aware that W|X will do some interesting things as well when people start trying to use all the memory (it's about as effective as not having anything at all).

      4. By Anonymous Coward () on

        I have to agree with whoever is writing the pro-PaX comments here. For what it's worth, since the recent "security problems" that hit the OpenBSD scene, the entire team has taken a different path that what the users were used to.

        Non-exec stack is the perfect example for that. And I also have hard time believing none of the OpenBSD developers ever heard of PaX, considering it was pretty known to anyone who was following main stream security mailing lists... (such as Bugtraq)

        As for TedU... That's one person who's doing lots of porting of code from NetBSD folks. He's lurking (at least) on NetBSD's kernel mailing lists, and whenever anything that's posted gets enough comments or gets commited, he ports it to OpenBSD. Subscribe to tech-kern@netbsd.org and see for yourself how lots of "cool patches from tedu" make it there a week or so before. ;)

        That's why I believe he copied the PaX code without crediting them.

        So, dear OpenBSD team, please bare us all of your crap about not hearing of PaX before they started bitching (or should I say - request honest credit for their work?) and start being full-disclosure about anything that's going on OpenBSD, like you say in your security page. Maybe most of the OpenBSD user base is compiled of idiots who'll buy anything Theo or anyone else says, but for those who know their shit you look pretty pathetic. :)

        And I'm an OpenBSD user.

        Comments
        1. By djm () on

          PaX never had a monopoly on the idea of a non-exec stack, or many other of the protections they claim to have invented. IIRC Solar Designer did the first non-exec stack for Linux years before PaX, many of the other protections have been implemented before on non-Unix platforms or are logical extensions from non-exec stack. By the PaX team's own admission, W^X is a completely different approach to what they do (IIRC they say it is worthless too), so it is facile to claim that it is a copy. E.g. the idea of randomly mapping shared libraries was implemented by Solar too, and randomising all allocations of a logical progression from there.

          Why do PaX think that they are the only ones to have good ideas?

          Comments
          1. By Anonymous Coward () on

            And how do OpenBSD developers treat other people/groups who audit their software? As if it were they that thought first of "code sweeping for new bugs".

            Not to mention that PaX gives credit and reference to those who deserve it on their website. OpenBSD not only lied about not knowing about PaX (and you can keep your claims and justifications to yourself, we both know you knew about it the same way I did) but it obviously copied -- even if you only depend on time frames, previous work patterns, release dates, and depth of documentation -- features from PaX.

          2. By Anonymous Coward () on

            solar did not randomly map libraries. He merely moved the base to have a null byte in most library addresses. randomizing all allocations is NOT a logical progression from there. Since Solar is in favor of features that provide security without a performance hit, which randomization does, and it was such a logical progression as you claim, why didn't he do it himself?

            Also, you don't remember correctly. The PaX team has never claimed W^X is worthless.

            vma mirroring in PaX is not a logical extension from a non-exec stack.

            the only thing in common between PaX and Openwall's non-exec stack is that they use the segmentation logic of the processor. Intel developed it for this reason, so no one "invented" it.

          3. By Anonymous Coward () on

            Did PaX not develop the only page-based non-executable page implementation on i386?
            Did PaX not develop the same features for more architectures than you support?
            Did PaX not develop the first implementation of proper kernel page permissions?
            Did PaX not develop the first implementation of FULL address space layout randomization?


            As far as I can tell, they're the only ones that have any good ideas.

          4. By PaX Team () pageexec at freemail.hu on http://pageexec.virtualave.net/docs/

            1. "PaX never had a monopoly on the idea of a non-exec stack"

            indeed, since PaX has never been a mere non-exec stack implementation. if you had cared to read the docs, you would know better. also i don't quite get what 'monopoly' has to do here, care to explain?

            2. "many of the other protections have been implemented before on non-Unix platforms"

            can you provide me with more details? i assume you're talking about full randomization and the non-exec page implementation and the rest - in my search on the net i could not find a single system that implemented them at once in a consistent, well-designed manner as PaX does it (if you read PaX docs, you'd know why a systematic approach in deploying the PaX defense mechanisms matters so much).

            3. "By the PaX team's own admission..."

            where is that admission? i'd really like to see it. if i admitted anything so far it was that W^X is the same *idea* as what i call NOEXEC in PaX (again, i'll refer to the docs to understand what that covers). as for my claim that the OpenBSD *implementation* is worthless, i don't think i ever stated that, but i will say now that it's less than ideal (read: subset of what PaX implements) for no good reason. it's your choice to not fix your code and make it better, not mine, don't blame me.

            4. "the idea of randomly mapping shared libraries was implemented by Solar too"

            i don't know where you got that from, but his linux patch has never had randomization in it, he remaps libraries so that the MSB of the addresses is 0 (Exec Shield does the same), but they all end up at the same place in repeated runs.

            5. "Why do PaX think that they are the only ones to have good ideas?"

            i don't, but you keep trying to put words into my mouth, you could really stop that now and invest your time in studying the topic you make claims about, the PaX docs would be a good start.

  9. By James A. Peltier () james@site-fx.net on http://www.site-fx.net

    When I first began reading the comments to this thread I began thinking that one of my favorite web sites was turning into another "troll fest of useless comments" like slashdot. It was nice when near the end "Anonymous Coward" and "tedu" began to discuss things in a more civil manner. It's since peaked my interest as to what each package (PaX/W|X) offers.

  10. By Elvis () on

    Damn IF we steal code from PaX and It's derived from SysV work...
    Besides I really dont care about PaX after all, probally when they get their crap in main linux kernel BRANCH we can talk again.
    Btw please save the whales

    Comments
    1. By Anonymous Coward () on

      Yea, because if it's in the main kernel, that completely changes how effective the code itself is. I'm glad idiots like yourself use OpenBSD. It's a good match.

      Comments
      1. By Elvis () on

        Hmmm because it isnt in main kernel tree its better?
        Wow Im amazed!

  11. By PaX Team () pageexec at freemail.hu on http://pageexec.virtualave.net

    i'll respond to a few points raised in one post lest it gets lost in the noise...

    1. "OpenBSD developers don't give a fuck what features PaX provides! They just don't look at PaX (not at their source, nor at their documentation)! They come up with these features themselves. Why do you trolls keep having a hard time believing this?!"

    let me begin with this one, as it probably highlights the core of the problem. contrary to what the claim would have you believe, said developers do care about PaX but not for the reason you think - i'll spell it out now because it seems to have been lurking in the background all this time but noone voiced it. consider why OpenBSD exists and why it is being used: mostly it's because of their various security related claims. i won't go into the validity of those claims, but i'll point out that apparently whatever they had achieved by mid-2002 (the time when certain 'high-profile' bugs surfaced) made them look for more security, stuff that's called intrusion prevention techniques in the commercial world (Entercept and others). whatever the origin of their techniques, they had clearly realized since that theirs was not the only one, and not even the best one for that matter - this means that their main claim to existence was in danger, OpenBSD is (and was) not the 'best' (security-wise, here it means 'resistance to exploits' which they care about the most, at least the infamous claim on their homepage makes one believe so). in my opinion it is for this reason that they chose to avoid any mention (let alone comparison) of PaX ever since, OpenBSD would simply not stand up, and coming from the developers' mouth would make them look bad (or so they seem to think).

    you also make a claim about the origin of their features without showing any proof - the few links you provided are just the same tiring rehash of the question i had asked (and never got a response to) since the beginning: where's your development process documented? apparently you don't know any better, why don't you just quit this silly war of the words until you do?

    2. "Please could you in favour for Random Memory Allocation Protection Method show some research papers on this sumbject for the community?"

    http://seclab.cs.sunysb.edu/addr_obfs/docs/ao.pdf
    http://www.crhc.uiuc.edu/~junxu/Papers/TechReport_TRR_UILU-ENG-03-2207.pdf
    http://www.usenix.org/events/sec03/tech/cowan.html

    not sure if you have access to USENIX, but you can try google/the authors' homepages.

    3. "256MB is a reasonable amount of VM space to burn on fragmentation"

    if your sshd maps 8 libraries, that's a 1GB (on average) of reduction in the largest mapping possible, if it's of any indication of a typical app, some of them might not be happy about it (the same apps you were referring to when you pointed out the halved address space under SEGMEXEC and Theo did the same a while ago in private mail - one wonders how/why he let this change fly now...). the very first version of ASLR in PaX did the same (per mapping randomization) by the way but it was found to be not worth it. if you think about it, there are two enemies of randomization: information leaking and attacks where absolute addresses don't have to be known. for the former, per library randomization is pointless because you never know (cannot guarantee) what parts of the address space can leak, so why bother? for the latter, it is pointless again for libraries because you cannot have overflows that cross ELF file mappings (there will be a non-mapped region or a r-x mapping between two rw-, unless you expect overflows from static data to .bss in a given library, but then you cannot randomize the gaps between such). it may matter for anonymous mappings provided they are used for all malloc() requests, something that's rarely the case (i don't know about OpenBSD, but on linux/glibc by default only requests above 128k are satisfied via mmap()). you said you were going to use mmap() for malloc() requests, i assume you meant those only that are above the page size, otherwise you'd be wasting lots of memory (something like ElectricFence does). in this case putting a random gap between them is pointless again, just have a non-mapped page and your overflows are stopped cold. in short, i see no reason for per mapping randomization.

    4. "calling people liars when they haven't told a lie isn't very nice."

    let's hope you keep reminding Theo about it as well.

    5. "So of all these projects only OpenBSD blindly copied PaX and the others didn't? These Windows implementations of the PaX ideas are independent and when OpenBSD claims they developed this independantly, you keep bitching on mailing lists and websites."

    a few words on the projects linked to on the PaX site. the windows versions have been developed based on the PaX documentation (note that contrary to a claim made here, i didn't develop either of them myself, although i did talk to the guys about various problems that popped up), they both acknowledge it on their respective sites - something you cannot really say about OpenBSD (i'd like to note that when Theo said on bugtraq the other day that he hadn't read anything where PaX was announced/talked about in the past... well, he was not saying the truth, namely he had been reading bugtraq itself where PaX showed up a few times... go figure). you guys keep saying that you had developed all this independently, yet when asked for evidence, silence is your response. will you too go silent now?

    by the way, the description of Exec-Shield is there to point out its non-executable page features, not the randomization ones (otherwise i should have put up many more links to other randomization projects that popped up over time, they'll be mentioned/analyzed in a future document though).

    6. "what happens when an attacker overflows A? he hits B. so if you know that writing 172 bytes past A will corrupt B in such a way as to lead to an exploit, no amount of adjusting the base helps."

    i think what you're getting at is a dead-end, it has been done in the past and is called ElectricFence and it's unusable in production (although really great for debugging).

    7. "how does PaX prevent overflowing A from overwriting data in mapping B?"

    PaX doesn't prevent any kind of overflow, it is simply not the goal (or hasn't been so far, this may very well change in the future). the goal is to prevent exploit techniques from working, read the documentation for details. your particular attack scenario allows for what i called the 3rd type of exploit technique (data modification) for which PaX explicitly provides no protection yet (again, it's clearly spelled out in the docs).

    8. "you can only do this if you disable mprotect. that's not an option."

    not sure where you got this from, but PaX does not disable mprotect(), what it does is that it prevents certain page protection combinations which is perfectly valid according to POSIX.

    9. "the per-page ness was a lot more complicated than W^X. you can get pretty close using just the hardware without having to reimplement stuff in software."

    i assume here you're talking about i386 and vma mirroring, as on the other archs it takes next to no code to get per page non-exec protection. have you got some comparison as to how much effort/code it took in OpenBSD to accomodate userland to your solution (ld.so i think)? also, i don't understand what you were referring to by 'reimplement stuff in software'.

    10. "Sorry, OpenBSD doesn't provide proc/pid/maps and /proc/pid/stat like PaX."

    actually, PaX doesn't provide them either as it is the /proc filesystem in linux itself that does and if you care to read the docs, you will find out why i didn't touch this code (hint: PaX is part of bigger systems that may and do want to do it their way, so why interfere).

    11. "have you considered that we might be trying to switch to mmap-based malloc?"

    this is an interesting statement, earlier this year Theo told me the following in private mail:

    ---------------------------------------------
    > how is the brk() managed heap mapped/handled/used in OpenBSD? would
    > malloc() not use it for 'small' allocations (like it does in linux)?

    brk is not used.
    ---------------------------------------------

    so what gives?

    12. "maybe the application your attacking doesn't have any bad format strings?"

    this maybe of some interest: http://marc.theaimsgroup.com/?l=bugtraq&m=105941103709264&w=2

    Comments
    1. By djm () on

      Nice to see a PAX advocate not hiding behind anonymiser (for a change). At least the OpenBSD developers do their flaming in public.

      Comments
      1. By Pax Team () pageexec at freemail.hu on mailto:pageexec at freemail.hu

        i'm not merely a PaX advocate, i'm the author of PaX. as for the flaming, i have nothing to do with it, i don't get why you guys keep attributing it to me (or assume i have any control over it). or are you suggesting that OpenBSD works that way? tedu/gwyllion/etc are flaming every now and then because they get theirs orders from higher up?

        Comments
        1. By djm () on

          I don't recall attributing anything to you, though you should know by now that your "advocates" are pure poison to your project's repuation (as are demands for credit). It makes you all look like petulant children.

        2. By gwyllion () on

          as for the flaming, i have nothing to do with it, i don't get why you guys keep attributing it to me (or assume i have any control over it).

          It's confusing to distinguish between PaX advocates (e.g. spender and noir) and the official PaX team if all the PaX advocacy is posted using anonymizer.com. Before you made a post with an actually name and real IP, I was under the impression all the flaming was done by actual PaX representatives. Sorry.

          or are you suggesting that OpenBSD works that way? tedu/gwyllion/etc are flaming every now and then because they get theirs orders from higher up?

          Tedu is an OpenBSD developer defending his work, which is being called inferior to PaX. I'm just an simple OpenBSD user, annoyed but all this PaX advocay/troll on this website; I do not receive orders from higher up (I don't know Theo personally, I never exchanged private email with him, ...).

          Comments
          1. By Anonymous Coward () on

            I'm sure neither spender nor noir have the time to bother with posting on this website. They're busy enough with their own projects. Why do you accuse people of things you have no proof of? You're committing the same act you're flaming others for.

            If you read, the PaX team did not ask for credit, but for their development timeline to be properly documented. When OpenBSD's development is shrouded in secrecy with private mailing lists, why should they be believed when they claim to have *thought* about something at a certain time, when they have no proof other than their own word to back it up?

            Comments
            1. By gwyllion () on

              I'm sure neither spender nor noir have the time to bother with posting on this website. They're busy enough with their own projects. Why do you accuse people of things you have no proof of? You're committing the same act you're flaming others for.

              Sorry, you must have misread my post. When stating PaX advocates (e.g. spender and noir) I was merely giving examples of PaX advocates who are bitching the OpenBSD project. See noir on bugtraq , noir on bugtraq 2 and spender treatening to release a local remote exploit for systrace and bitching about an unimplemented feature (W^X on PPC) . I could have stated Peter Busser as well (as a PaX advocate), but I didn't because he's polite in comments on PaX vs OpenBSD.

              Sorry, I didn't want to suggest that spender and noir are acting as trolls on this website.

              Comments
              1. By Anonymous Coward () on

                and Theo was polite and completely unprovoking in this regard? Need I remind you of:

                http://marc.theaimsgroup.com/?l=openbsd-misc&m=106573542723629&w=2
                http://www.securityfocus.com/archive/1/333462/2003-08-15/2003-08-21/2
                http://www.securityfocus.com/archive/1/333899/2003-08-15/2003-08-21/2

                There are many more examples, as I'm sure you are aware, but I don't need to waste any more time on it. Why do you always exempt Theo from your criticism of people bitching and whining? Theo's post on misc makes him look silly. Is it your position that you enjoy having such an immature person as the leader of OpenBSD?

                Comments
                1. By djm () on

                  Theo *is* polite and reasonable compared to the PaX advocates:

                  http://www.deadly.org/commentShow.php3?sid=20031009110855&pid=315
                  http://www.deadly.org/commentShow.php3?sid=20031009110855&pid=451

                  ... and this is just a small sample from this forum. I'd say that calling people idiots is nowhere near as bad as calling them plagarists.

                  Comments
                  1. By Anonymous Coward () on

                    And Theo didn't call the PaX team liars? What's the difference?

                    Comments
                    1. By djm () on

                      yeah, he called them liars after they pseudonymously posted to mailing lists that the OpenBSD project has stolen code/ideas from PaX.

                      Comments
                      1. By Anonymous Coward () on

                        The PaX team posts as the PaX team. Please show proof of where THE PAX TEAM said OpenBSD stole code or ideas. All i see is them asking for proof of their development time line, which is a valid request. This request has not been fulfilled, while Theo continues to whine and bitch.

                        Comments
                        1. By Can Erkin Acar () on

                          The PaX team posts as the PaX team. Please show proof of where THE PAX TEAM said OpenBSD stole code or ideas. All i see is them asking for proof of their development time line, which is a valid request. This request has not been fulfilled, while Theo continues to whine and bitch.

                          And what does asking for proof of development time line means, really? What kind of proof do you expect?

                          Does PaX developers obtain signed timestamps for every idea they have thought/written/implemented from a third-party trusted source?

                          Every other proof you can get is exactly TRUSTING the WORDS of the DEVELOPERS. When they say: "no we did not know PaX existed at the time we thought of these things" that is enough proof. After that you start calling them liars.

                          This is what "The Pax Team" did. Reading his posts again, it seems to me that (s)he loves to write open statements that imply many things without saying them outright.

                          Comments
                          1. By Anonymous Coward () on

                            surely they should have something on paper. PaX made their initial documentation public. Is it impossible for the OpenBSD developers to show ONE message from their private mailing list about when they were developing W^X before they had heard about PaX? Clearly they should have this kind of documentation. There have been many conflicting reports from various OpenBSD developers regarding when they actually heard about PaX. OpenBSD is creating the problem by not being clear and truthful about when they first heard about PaX. PaX was mentioned on openbsd-misc and bugtraq, which Theo reads, years before Theo ever started talking about W^X. Niels Provos attended a presentation in france that discussed PaX a year before Theo ever started talking about W^X (at this time, Niels was still an OpenBSD developer). This was also around the time of the released OpenSSH exploit. Are you telling me that Niels never talked to Theo about what he learned at the presentation? Are you telling me that no other OpenBSD developers read openbsd-misc or bugtraq either? You don't have to be a brain surgeon to notice that with the facts that are available, things just don't add up in OpenBSD's favor. Thus it would be nice to see proof other than their varying personal explainations.

                            Comments
                            1. By Can Erkin Acar () on

                              Is it impossible for the OpenBSD developers to show ONE message from their private mailing list about when they were developing W^X before they had heard about PaX? Clearly they should have this kind of documentation.

                              For what? If you do not trust their words, why would you trust any mail/documentation they give to you. And why would they, knowing that such proof would also be debatable, bother digging up their archives/documents for some proof?

                              You see, I do not remember when I first heard about PaX either. Although I am absolutely sure I heard about it much earlier (possibly in bugtraq or some conference announcement etc) I did not _know_ what PaX _is_ until this whole debate started. While you might argue that I am much clueless than most of the OpenBSD developers, It is entirely possible that PaX was ignored as 'some Linux thing' even if it was noticed.

                              So, you have to trust the developers. They have nothing to lose by giving credit to PaX they already give alot of credit to all kinds of people, organizations and projects. The BSD license itself is only about giving credit. The fact that they do not give credit, then, is because they did not know PaX at the time W^X was designed.

                              Comments
                              1. By Anonymous Coward () on

                                They have a lot to lose by crediting PaX, though you might not understand their reasons. What they lose by crediting PaX is EGO. Crediting PaX shows that they aren't #1 for security in the industry as they strive to be. If the mailing list mails exist, show them. I'm sure not all of the OpenBSD developers would lie just to save face, so whatever mails that were produced would be trusted. When you have reports from Theo that don't involve anyone else about when he "invented" the idea of W^X is when the veracity of statements are questioned. Though I doubt we will ever see those mails now, because I'm sure they show contrary to what Theo has told everyone, and there's no way he'd let his character and ego be ruined.

                                Comments
                                1. By Anonymous Coward () on

                                  Crediting Pax does none of this, and it is childish to see that think that is the reason they do not credit Pax. If you actually looked at the code for Pax and W|X, you will notice that they attempt to solve similar problems, but they go about it in completely different manners. I do not wish to debate which method is better, because frankly, I don't know enough about each implementation, but sefice it to say that concurrent solutions to widely accepted problems can and do happen all the time. Get over it.

                                  Comments
                                  1. By PaX Team () pageexec at freemail.hu on mailto:pageexec at freemail.hu

                                    "If you actually looked at the code for Pax and W|X, you will notice that they attempt to solve similar problems, but they go about it in completely different manners."

                                    not merely similar problems, but exactly the same problem (prevention of certain exploit techniques). and the manners are the same too, separation of the writable/executable attributes on memory pages and a generic safety net via randomization of various pieces of the address space. the implementations are different for obvious reasons though (and sometimes for not so obvious reasons).

                                    Comments
                                    1. By Anonymous Coward () on

                                      In 1989, as a new student of electronics (training in Weapons/Military), I personally discovered Digital to Analog Conversion and applied it to my current project. Having never heard of it before.

                                      I was pretty amazed looking through some text books on the subject, which my professor pointed me to after seeing my work.

                                      Harnessing a hardware feature of some lines of CPU's and then extending on it (in parallel projects), can hardly go very far without heavy overlap.

                                2. By henning () henning@ on mailto:henning@

                                  They have a lot to lose by crediting PaX, though you might not understand their reasons. What they lose by crediting PaX is EGO. Crediting PaX shows that they aren't #1 for security in the industry as they strive to be.
                                  That's simly wrong. We have nothing to loose with crediting PaX. W^X and the randomnization stuff is only a small fraction of what we do for security in OpenBSD.
                                  It's simply that we indeed didn't know any details of PaX at the time the dieas for that came up. Personally, I heard about PaX before, without knowing or really caring for what it is.
                                  There was no mention of PaX on our internal mailing list or the internal icb channel before some PaX advocates started bitching.

                                  Comments
                                  1. By PaX Team () pageexec at freemail.hu on mailto:pageexec at freemail.hu

                                    thank you very much for finally answering the first question instead of engaging in some meta discussion like so many others did before... i take it that your internal communication is your modus operandi but i'll ask the other questions anyway: why are these discussions kept secret and would you consider making them public (as i said before, not merely for my own curiosity, but in general)?

                          2. By Anonymous Coward () on

                            And what about now, since it's been several months since their "official" knowledge of PaX. How can you un-learn what you've read in someone's documentation? How can they claim independent discovery on the things they've been implementing recently that are duplicates of the work the PaX team has done?

                            Comments
                            1. By Can Erkin Acar () on

                              What makes you think they go 'wow PaX has this feature too lets implement it' ?

                              Once you start moving along a path (W^X, randomization, whatever) there are only so many things to can do to improve it. It is natural that some of the ideas are close. Furthermore, most of these 'duplicate' work are critisized by PaX team as being wrong or different - so how are they duplicates?

                              You seem to think OpenBSD is implementing PaX without telling the world about it. Has it ever occured to any you that OpenBSD may NOT be implementing PaX at all?

                          3. By PaX Team () pageexec at freemail.hu on mailto:pageexec at freemail.hu

                            not sure what i did to you that i deserved these wild accusations, but since you asked for it...

                            1. "What kind of proof do you expect?"

                            emails? irc/icb/etc logs? are you telling me that the OpenBSD development process is not documented? or if it is, it's kept secret? how come none of you guys addressed these questions?

                            2. trusting the words of the developers is a good point to raise given how many times said developers were shown to have made false claims, and i'm quite sure it's just the tip of the iceberg. forgive me if based on such background i won't give these guys the benefit of doubt.

                      2. By PaX Team () pageexec at freemail.hu on mailto:pageexec at freemail.hu

                        excuse me but this simply goes too far. please show me the evidence where i posted 'pseudonymously' stuff you accuse me of. if i have an opinion, i state it openly, just like here, i don't need to hide it.

                      3. By Anonymous Coward () on

                        You are acting like a politician now and avoiding giving us all an answer as to how does the OpenBSD development process works, why serious issues are discussed in private mailing lists, and we only get the final product.

    2. By Can Erkin Acar () on http://www.openbsd.org/goals.html

      Responses in the same order. <br> <br> 1. OpenBSD uses many technologies, and gives credit where it is due, but you can not find mention and comparison of similiar technologies in OpenBSD pages. There is NO mention or discussion of UBC, vinum, StackGuard, IIS, tinydns, postfix, FreeSwan or other technologies for which OpenBSD has provided a similiar functionality. Why would there be one for PaX? <br> <br> If you want comparison of PaX and OpenBSD features do it and publish it. It is very likely that a fair comparison, whatever the conclusions may be, will be linked from the press.html pages. <br> <br> Most of your postings in this forum goes on and on about _differences_ and discussions of how PaX features are superior to OpenBSD implementation. Since there are so many differences how can you still believe, and make others believe, that OpenBSD implementation is based on PaX? <br> <br> Why is it so important to you that OpenBSD makes such a statement, even when it is not true? <br> <br> 2. Thanks for the links. <br> <br> 3. Nice discussion, not my area of expertise though, so I prefer to trust OpenBSD developers to make the right decisions. See, this is after release hacking time where many large changes enter the tree to be tested and tuned by the users and developers. I believe that things will work fine by the release time. <br> <br> 4. You are asking Theo to lie by forcing him to tell OpenBSD W^X is based on PaX. <br> <br> 5. See reply 1. above. We do not - can not - comment on every possible similiar technology out there. Simply not possible: OpenBSD is an OS not a W^X project with a limited scope. <br> <br> 6. Then let it be used for debugging only. This is part of the job too, we are talking about a complete OS here. <br> <br> 7. Yep, different goals, different needs, different implementations. <br> <br> 8. Cannot comment, not my area, but from the discussion it seems that there are many ways to read POSIX. <br> <br> 9. No idea, sorry. <br> <br> 10. Again the same point: you have no control over the OS and you make your decisions based on that. OpenBSD W^X is part of the OS and both are developed together. There are lots of different design decisions between W^X and PaX so why not just leave it alone. <br> <br> 11. What tedu was talking about is obviously a different implementation, and Theo was also correct since: malloc.c rev 1.4 (7 years 2 months ago): "malloc(3) implementation from FreeBSD; uses mmap(2) to get memory." and it takes less than a minute to get this information from cvsweb. <br> <br> 12. Nice, new attacks, new things to audit and fix. You will find that most off-by-one problems are already fixed in the OpenBSD tree. See for instance the recent and extensive str* and realloc cleanups. <br> <br> Summary: Both projects have the same aim, make exploitation bugs difficult (PaX claims to stop them all, OpenBSD claims no such thing). <br> <br> Underlying principles are simple: prevent misuse of memory protections as much as possible, and randomize to make it difficult to use existing code and structures. There were, is and will be papers/publications/discussions and implementations on these subjects and you can not claim to have invented the concept. Or do you? <br> <br> OpenBSD is the OS so it can protect in layers by fixing and redesigning applications, and even introducing binary incompatibility when necessary. PaX have minimal control over the OS so it has different priorities and design decisions. <br> <br>

    3. By Can Erkin Acar () on http://www.openbsd.org/goals.html

      Arrrgh. do not use extended translation

      Responses in the same order.

      1. OpenBSD uses many technologies, and gives credit where it is due, but you can not find mention and comparison of similiar technologies in OpenBSD pages. There is NO mention or discussion of UBC, vinum, StackGuard, IIS, tinydns, postfix, FreeSwan or other technologies for which OpenBSD has provided a similiar functionality. Why would there be one for PaX?

      If you want comparison of PaX and OpenBSD features do it and publish it. It is very likely that a fair comparison, whatever the conclusions may be, will be linked from the press.html pages.

      Most of your postings in this forum goes on and on about _differences_ and discussions of how PaX features are superior to OpenBSD implementation. Since there are so many differences how can you still believe, and make others believe, that OpenBSD implementation is based on PaX?

      Why is it so important to you that OpenBSD makes such a statement, even when it is not true?

      2. Thanks for the links.

      3. Nice discussion, not my area of expertise though, so I prefer to trust OpenBSD developers to make the right decisions. See, this is after release hacking time where many large changes enter the tree to be tested and tuned by the users and developers. I believe that things will work fine by the release time.

      4. You are asking Theo to lie by forcing him to tell OpenBSD W^X is based on PaX.

      5. See reply 1. above. We do not - can not - comment on every possible similiar technology out there. Simply not possible: OpenBSD is an OS not a W^X project with a limited scope.

      6. Then let it be used for debugging only. This is part of the job too, we are talking about a complete OS here.

      7. Yep, different goals, different needs, different implementations.

      8. Cannot comment, not my area, but from the discussion it seems that there are many ways to read POSIX.

      9. No idea, sorry.

      10. Again the same point: you have no control over the OS and you make your decisions based on that. OpenBSD W^X is part of the OS and both are developed together. There are lots of different design decisions between W^X and PaX so why not just leave it alone.

      11. What tedu was talking about is obviously a different implementation, and Theo was also correct since: malloc.c rev 1.4 (7 years 2 months ago): "malloc(3) implementation from FreeBSD; uses mmap(2) to get memory." and it takes less than a minute to get this information from cvsweb.

      12. Nice, new attacks, new things to audit and fix. You will find that most off-by-one problems are already fixed in the OpenBSD tree. See for instance the recent and extensive str* and realloc cleanups.

      Summary: Both projects have the same aim, make exploitation bugs difficult (PaX claims to stop them all, OpenBSD claims no such thing).

      Underlying principles are simple: prevent misuse of memory protections as much as possible, and randomize to make it difficult to use existing code and structures. There were, is and will be papers/publications/discussions and implementations on these subjects and you can not claim to have invented the concept. Or do you?

      OpenBSD is the OS so it can protect in layers by fixing and redesigning applications, and even introducing binary incompatibility when necessary. PaX have minimal control over the OS so it has different priorities and design decisions.

      Comments
      1. By Anonymous Coward () on

        11. What tedu was talking about is obviously a different implementation, and Theo was also correct since: malloc.c rev 1.4 (7 years 2 months ago): "malloc(3) implementation from FreeBSD; uses mmap(2) to get memory." and it takes less than a minute to get this information from cvsweb.

        And if you grab the newest version of the source of malloc.c, you can see several uses of sbrk and brk. This also takes less than a minute, less than it took for you to falsely back up Theo and tedu. Theo is wrong. He says brk is not used, and it is clear that it is being used.

        pf->end = (char *)pf->page + malloc_cache;
        pf->size = malloc_cache;

        brk(pf->end);
        malloc_brk = pf->end;

        index = ptr2index(pf->end);

        result = (caddr_t)pageround((u_long)sbrk(0));
        pages SIZE_T_MAX - (size_t)result) {
        #ifdef MALLOC_EXTRA_SANITY
        wrtwarning("(ES): overflow in map_pages failsn");
        #endif /* MALLOC_EXTRA_SANITY */
        errno = ENOMEM;
        return (NULL);
        }
        tail = result + pages;

        if (brk(tail) == (char *)-1) {
        #ifdef MALLOC_EXTRA_SANITY
        wrtwarning("(ES): map_pages failsn");
        #endif /* MALLOC_EXTRA_SANITY */
        return (NULL);
        }

        Comments
        1. By Can Erkin Acar () on

          And if you grab the newest version of the source of malloc.c, you can see several uses of sbrk and brk. This also takes less than a minute, less than it took for you to falsely back up Theo and tedu. Theo is wrong. He says brk is not used, and it is clear that it is being used.

          uh! sorry, i was wrong. That is what you get for a minute of research. I have no other data to support or falsify Theo. You will have to ask him instead what he meant.

          Comments
          1. By PaX Team () pageexec at freemail.hu on mailto:pageexec at freemail.hu

            he meant what he said, here's a bit more context of the discussion (i could post the entire thread but it's private mail, so i won't until he says ok, feel free to ask him as well):

            -------------------------------------------------
            > > our trick which we are experimenting with is to put a 1GB gap between
            > > text & data into each elf executable and .so
            > >
            > > this results in greater fragmentation
            >
            > what would be the new segment layout? something like: CS: 0-1 GB,
            > DS/SS: 0-2 GB (or whatever the upper limit of userland is)?

            CS: 0 -> wherever the line needs to be
            DS/SS: 0 -> 3.25GB

            The line floats. Our pmap keeps track of the highest page that has
            PROT_EXEC permission, and puts the line just above it.

            Since we will have a 1GB gap, the code segments of each .so will be
            placed down below. The data will be offset 1GB higher.

            Memory fragments, but our malloc uses mmap, and therefore will use
            the gaps.
            -------------------------------------------------

            and the last sentence is what piqued my interest, so i asked and got this (you saw the latter part of it already):

            -------------------------------------------------
            > > Memory fragments, but our malloc uses mmap, and therefore will use
            > > the gaps.
            >
            > how is the brk() managed heap mapped/handled/used in OpenBSD? would
            > malloc() not use it for 'small' allocations (like it does in linux)?

            brk is not used.
            -------------------------------------------------

            Comments
            1. By Can Erkin Acar () on

              so Theo was wrong, realized the problem and now tedu is fixing it. Well, thank you for bringing it to his attention then.

              Comments
              1. By Anonymous Coward () on

                Theo didn't understand how his malloc implementation works? And this is his OS? That's not what you call wrong, that's what you call STUPID. Theo can never hold a technical conversation without being wrong. He's a fraud.

              2. By PaX Team () pageexec at freemail.hu on mailto:pageexec at freemail.hu

                i think you misunderstood something, the quotes were from this january, not something recent, and no, i didn't bring anything to his attention (mind you, when i did bring a POSIX violation to his attention, it didn't get fixed), as you can see i was merely asking a question (because i found it weird that brk() would not be used). as for realizing/fixing the problem... err, what problem? theo simply didn't know how their own malloc() implementation worked, there's not much to fix there (except reading the source code a few times over). but hey, thanks for the thanks ;-)

                Comments
                1. By Can Erkin Acar () on

                  As far as I can remember miod commented about this violation at the time. And it could be PaX that is violating POSIX depending on how the specification is read.

                  The problem with malloc, as described in the discussion with theo you have posted, is that it is using brk, thus wasting space with W^X. Solution is to make it use mmap which is what tedu is working on right now. Yes, they would probably have made this change regardless of your comments on brk, but thanks anyway.

                  Comments
                  1. By PaX Team () pageexec at freemail.hu on mailto:pageexec at freemail.hu

                    we are talking about two different issues. the one the theo spread turned out to be false, notice he stopped talking about it since. it's not only me saying it, miod also agreed:

                    http://marc.theaimsgroup.com/?l=openbsd-misc&m=105060862625412&w=2

                    the other issue i had raised in passing is a true violation in OpenBSD (and as you will see, in the other BSDs as well). first, the relevant info from POSIX/SUSv3:

                    http://marc.theaimsgroup.com/?l=openbsd-misc&m=105060560321916&w=2

                    if you compare it to the code i pasted earlier in the thread, it's obvious that OpenBSD does NOT follow this part because it checks for PROT_READ only but not PROT_EXEC:

                    --------------------------------------------------
                    EACCES
                    - fd was not open for read and PROT_READ or PROT_EXEC were specified.
                    --------------------------------------------------

                    again, it's not only me saying it (beyond being obvious to any programmer who understands C), but miod agreed as well (quote from a private mail i sent to him afterwards as i saw no point in beating this drum on misc@):

                    --------------------------------------------------
                    > > EACCES
                    > > - fd was not open for read and PROT_READ or PROT_EXEC were specified.
                    > > - fd was not open for write and PROT_WRITE was specified for a
                    > > MAP_SHARED type mapping.
                    > >
                    > > This is what SunOS
                    > No, OpenBSD does not, you don't check for PROT_EXEC, see my code
                    > snippet i posted on your list.

                    Indeed. None of the *BSD systems currently checks for PROT_EXEC in this
                    case.

                    Miod
                    --------------------------------------------------

                    as for the malloc()/brk() vs. W^X problem, i don't see why the need for the mmap() based approach. back in the first version it was indeed the only way because the highest executable mappings were those of the libraries so the brk() region would necessarily fall below that, but in the current version (as far as i checked, feel free to correct me if i'm missing something) the executable is mapped highest up in the address space, that is, libraries are all below it and after the r-x segment of the executable all you have is non-executable data mappings (file or anon), so you could simply set the CS limit just after the main executable's r-x segment and still keep using a now non-executable brk().

      2. By Anonymous Coward () on

        the fact that it uses mmap for malloc does not mean that malloc uses SOLELY mmap for allocation. Linux also uses mmap for malloc, but this doesn't mean it always uses it.

    4. By gwyllion () on

      Thanks for you long argumented comments.

      As for 3+6+12 (tedu's malloc guard pages imitating Electric Fence), have you read http://www.zeitbombe.org/openbsd.html ? It clearly states that this feature is similar to Electric Fence and very usefull as a debugging mechanism (recently a number of bugs were discovered with it):
      Guard pages and free page protection in malloc(). Again, add an unmapped page (technically, mapped with protection PROT_NONE) after each page size or greater allocation (including after each page of chunks). Also includes an option to mprotect all free pages, so that use after free results in a crash. Basically, attempts to provide some features of electric fence in the system malloc without impacting performance too badly. Running with this patch has allowed developers to catch numerous bugs that went undetected before.

      If I look at the implementation ( http://www.zeitbombe.org/malloc_guard.diff ), it's implemented as an extra malloc option (like "Junk", etc.). So I guess it will not be used by default and mostly used as a debugging tool.

      Comments
      1. By Brad () brad at comstyle dot com on mailto:brad at comstyle dot com

        With ted's malloc diff the feature is enabled by default, using malloc option 'g' will disable it.

    5. By tedu () on

      the 256mb VM burned is total, not per allocation. this is effectively similar to moving mmap base, but every allocation has a new mmap base (starting from the same original base). while the effect of our randomization achieves the same as PaX, it goes one step further. one AC couldn't understand the goal, but you seem to realize that data modification attacks can be prevented by guard pages and/or avoiding a linear address space.

      the malloc guard stuff only works for after each page. smaller allocations are not as protected.

      why still random with guard pages? why not? also, attacks are becoming more sophisticated. we are trying to reduce the amount of information an attacker knows. if you don't know where the library is, if you don't know where the buffer is, if you don't know where your target to overwrite is, things become more difficult. with only the ASLR you have (and not the X bit stuff) the sshd exploit from last summer would still have been effective i believe. more tries likely, but not impossible for a dedicated attacker. with guard pages, it would be impossible. with randomized allocations, it would have been much harder than simply with random base. name of the game is defence in depth.

      at the moment, the heap is not randomized. we will not simply push it around, as PaX has done. 1. that would be copying. :) 2. we think we have a better, more complete solution.

      "PaX provides no protection against data modification" or so.
      we are trying to do this. the idea is similar to electric fence, but with a different target (security vs debugging), and additionally designed so that it can be run all the time with minimal impact. can it be done, and at what cost? wait and see.

      cost of vma doubling vs. ld.so.
      i don't have a good way of estimating how much effort went into developing each approach. once you get past the initial recompile though, imo ld.so is less intrusive. it certainly permits more complete utilization of the address space.

      at this time malloc uses brk for most memory. more than one mmap implementation already exists, but not comitted.

      Comments
      1. By Anonymous Coward () on

        That's nice and all tedu, but what good does it do someone with openbsd 3.4 who gets owned via the non-randomized PLT?

        I'm sure you don't go around telling everyone that simply pointing their exploit into the binary image instead of the things you have randomized will bypass all the work you've done. In fact, I know you don't, and I know it will never be mentioned on the openbsd mailing list or anywhere else by openbsd developers. I don't see how you can even make a comparison between your randomization and full ASLR.

        How about solving real problems instead of adding more useless randomization features?

      2. By PaX Team () pageexec at freemail.hu on mailto:pageexec at freemail.hu

        "data modification attacks can be prevented by guard pages and/or avoiding a linear address space."

        some of them yes, but in general you need much more than that. since you have never stated your threat model, i'll assume here what i used in PaX: bugs that give arbitrary read/write access to the address space (everything else is a subset of this). let's concentrate on the write part here only, such an ability means that guard pages, your non-linear mappings mean nothing, they will be bypassed. where your proposed methods are effective is when you have a so-called linear buffer overrun error (the classical strcpy() and others), there are other classes of bugs that need not care about buffer boundaries.

        Comments
        1. By tedu () on

          "in general you need much more than that."
          certainly.

          i didn't say it was effective against all errors. guard pages are a defense against one particular attack type. they are also really handy for debugging. we can protect against an overrun, therefore we will. you appear to have simply chosen to disregard this form of attack (for now).

          i don't think your argument is "you can't protect against everything, so don't bother with anything" but that's what it sounds like. if this isn't effective against one form of attack, then we develop something else. but "it's not 100%" is no reason not to develop such solutions as we can.

          "bugs that give arbitrary read/write access to the address space"
          nothing i see in PaX definitely prevents exploitation either. you prevent arbitrary code execution, but not read/write.

          Comments
          1. By Anonymous Coward () on

            And you prevent neither.

          2. By PaX Team () pageexec at freemail.hu on mailto:pageexec at freemail.hu

            1. "you appear to have simply chosen to disregard this form of attack (for now)."

            it's not the correct way to put it. what i decided to do in PaX (does anyone read the docs...?) was to prevent *exploit techniques* from working (this is what i normally refer to by 'attack'), not *triggering the bug in the first place*. your guard pages (as a subset of runtime bounds checking) belong to the latter category, W^X and randomization to the former. in any case, if you read the future plans for PaX, you'll realize that there will be attempts at solving the more fundamental problem.

            2. "i don't think your argument is "you can't protect against everything, so don't bother with anything" but that's what it sounds like."

            better put, my argument is that why waste resources on solving a subset of the bigger problem when you can solve the bigger problem itself with the same/better efficiency? in this case (preventing a bug from getting triggered) the bigger problem can be solved by doing full runtime bounds checking - question is how you can do it (much) more efficiently than existing solutions. we'll see if i manage to do it ;-).

            another way to put my argument is that why solve the problem up to 90% instead of 100% and not be able to give guarantees about the protection? you'll probably ask why guarantees matter so much: whenever a new bug gets discovered, i will still sleep better because i will know it won't be exploitable whereas in your approach you may or may not be exploitable, but you don't *know* until you actually look at the bug, analyze it and decide whether it's exploitable under the given circumstances or not. sure, it may very well be possible that 99% of these bugs turn out to be non-exploitable in your system as well, but it's the 1% that gets you owned and i'd rather not let that slip by, especially since it is possible to prevent it.

            3. "nothing i see in PaX definitely prevents exploitation either. you prevent arbitrary code execution, but not read/write."

            correct, that's why the project is not over yet ;-), but nevertheless, this is the goal (it's nice to have one, isn't it). interestingly enough, combining the current techniques with a simple ACL system does already provide a certain level of protection in the face of arbitrary read/write access as well, something you cannot claim for OpenBSD (for now at least).

      3. By Anonymous Coward () on

        "name of the game is defence in depth."

        Exactly when did the game become defence in depth for OpenBSD?

        Do I really need to refer you to OpenBSD developers making comments against such work? Preaching on the auditing of code?

        "False sense of security" (Marc Espie)

        "but it's just not a priority for any of the developers." (Dug Song)

        When did features like non-exec stack become real security features, and a priority for the developers? After all of you got owned. Dug Song got owned, OpenBSD got owned, and your pro-active auditing did exactly 0. These features being added now are pure retro-active actions taken to protect yourself from further embarrassments from mistakes you have in your code, so it's not exactly your code auditing process, that uncovered "thousands of bugs" that's making your OS pseudo-secure, but the features you add now, all the randomization hype and the stuff you copy from PaX, that you rely upon for security.

        OpenBSD may look a secure OS alternative for a new user, but for a bystander who's been with OpenBSD for years (since 1997-8?) you just look sad. Provide your userbase with information as to why now non-exec stack, W^X, and all the other "cool stuff" you add every once in a while is important and in 1999-2001 it wasn't. It's those half words and almost "e-stuttering" that Theo does that makes -- at least me -- look less and less of OpenBSD with time.

      4. By Anonymous Coward () on

        http://www.netsys.com/openbsd-misc/1999/12/msg00862.html

        More proof that these recently added security features to OpenBSD are just to save your own ass from losing your so-called reputation. Code auditing isn't very useful when you have no clue what you're looking for huh? :)

        Go back to lurking on NetBSD mailing lists, Ted. I hear David Laight has some new shit running. ;)

        Comments
        1. By djm () on

          That is hilarious. You post a mailing list comment from *four years ago* as proof that OpenBSD is losing its reputation. A lot can happen in four years.

          Comments
          1. By Anonymous Coward () on

            First of all I'd appreciate if the more significant developers for once would comment on that.

            Even though the message is from four years ago, the reason it was posted was that the OpenBSD policy, back then, was that code auditing is the solution to all problems. Do you mind telling us what changed your mind, especially during 2002-2003, that these band-aid solutions are necessary in an pro-actively secure OS like OpenBSD?

            My guess: Your auditing process proved useful, but not useful enough, and all the solutions that you used to call workarounds protected against stuff your code auditing process never could.

            If that's not the reason, please tell us otherwise. And if that's the reason, how can you explain all the bad things you've said about what goes into your kernel these days? :)

            Comments
            1. By djm () on

              First, don't make the mistake of thinking that all OpenBSD developers are of one mind on every subject - OpenBSD is a community, not a dictatorship. Second, I can't speak for any of the developers who actually did the work.

              Personally, I have always liked the idea of kernel-side protection systems so there was no changing of my mind involved. I'm sure the other developers have other stories. Why don't you ask the ones who committed the changes?

              I don't think that these techniques diminish the importance of auditing. Not every bug is a stack overflow - many are simple logic errors or inappropriate trust placed on attacker supplied data. Fancy memory protection mechanisms do little to prevent these classes of bug. (I know from recent, bitter experience)

              Also, what to what do you refer when you say "the bad things you've said about what goes into your kernel these days"? I don't recall saying anything either way.

              Comments
              1. By Anonymous Hero () on


                A further topic is, naturally, security. Theo points out that an absolutely secure system would imply a bugfree system and thus is not possible, and briefly explains ProPolice and W^X. A small followup article focusses on the basics of ProPolice and W^X.

                http://www.openbsd.org/press.html june 2003

                me looking forward to the real openness of projects like OpenBSD. How are things decided? Consensus?

                Comments
                1. By Anonymous Hero () on

                  Asked about Linus Torvald's role in Linux Theo desribes his role in OpenBSD as a "friendly dictator" who is involved in all major decisions.

  12. By Michael () on

    Dear tedu,

    Thanks for your contribution. Sorry that a flamefest ensued.

    --Michael

  13. By scbontra () on

    I use openbsd because it has been, over the long haul, the most secure OS out there that runs on my hardware and gives me the features I want. I'm just a user--my view is worthless beyond that.

    I don't care if PaX had idea(x) 3.74 seconds before OpenBSD did. The fact remains that OpenBSD did independant development, unless PaX has a patent on the process or there is copyright violation going on, I don't care who thought the thought first. As pretty much everyone agrees (except maybe SCO's lawyers) the developement was seperate and there isn't a copyright violation.

    Neither the GNU or BSD license requires you to give credit for the IDEA, only the implementation. If the implementation was done seperately there is no legal basis to demand anyone give anyone else credit.

    Personally, I tend to buy the disperate-origions/ same-conclusion argument. Smart people (which most of us here are, save a few of the obvious trolls) tend to have good ideas. Good ideas all tend to be in the same direction. It's quite possible that all these good ideas happened around the same time. Maybe it's something in the water.

    But, in the end, it's all about me. I decide what I want to use and why. OpenBSD or PaX can both have great ideas and great implementations but if neither meet my needs I won't use it. If I --NEED-- a feature in PaX I'll go build myself a Linux system and load PaX up. If OpenBSD continues to provide a consistantly good security record (a few misses here and there is still far better than anything else out there) then I'm going to continue using it and GNU/Linux/PaX won't get my $$$.

    The unstated goal of the BSD camp is to make all software BETTER. The clearly stated goal of the GNU camp is to make all software FREE. I for one see these two goals pretty much in line with each other. Asking for credit for an IDEA is pretty anti-GNU from my vantage, it smells an awfully lot like a patent. If OpenBSD wants to take an IDEA like DNS or SSH or W^X and write a BETTER implementation of it (without violating copyright law/licenses) then why are you complaining? If PaX likes an IDEA in OpenBSD's setup they can take it too.

    It's purely academic if PaX or OpenBSD's approaches are technically better. I'd love to read a full breakdown of the two. I'd like it even more, for my own selfish reasons as a user, if the best bits of both were integrated together--which is the general direction of OpenBSD anyways.

    Comments
    1. By Anonymous Coward () on

      Sums up my thoughts nicely :)

    2. By PaX Team () on mailto:it's all over the place now ;-)

      what you missed in your post is that the core of the problem is not whether OpenBSD invented stuff independently or not, but that we (and you) simply don't know. i have had exactly one request towards the developers: make your development process publicly accessible. until then you can blame only these developers if people substitute hard facts with their speculation.

      you brought up a lot stuff that's irrelevant in this case, there has never been an issue of GNU vs. BSD, copyright violations, trademarks, patents, what have you, it's merely the lack of information on the OpenBSD development process (it's somewhat ironic how closed it appears to be).

      Comments
      1. By djm () on

        So now that you admit to not knowing, you can stop casting wild aspertions.

        You ask the OpenBSD team to "open up", but you are asking us to prove a negative - obviously impossible.

        If developer conversations were made public, you could always accuse us of hiding things (which can't be provably denied) or doing it by private email. Would you then demand the our private mailboxes too?

        There is really no way to exonerate oneself from such an accusation. I'm sure you know this.

        Comments
        1. By PaX Team () pageexec at freemail.hu on mailto:pageexec at freemail.hu

          1. "So now that you admit to not knowing, you can stop casting wild aspertions."

          what are you talking about?

          2. "You ask the OpenBSD team to "open up", but you are asking us to prove a negative - obviously impossible."

          wrong, it'd be something like 'grep -ir pax secret_openbsd_developer_archives/'. you said 'us', does it mean you are an OpenBSD developer? if so, can you answer the following questions:

          - have you got developer discussions and logs that are not available to the public?
          - can you make them public, if not, why not?

          3. "If developer conversations were made public, you could always accuse us of hiding things (which can't be provably denied) or doing it by private email. Would you then demand the our private mailboxes too?"

          are you looking for excuses? please answer the question of why said development process is not public at all, it's NOT normal that i have to ask for them to begin with (and i'm sure many others would be interested in them too, for different purposes). if you had kept your development all open over the years, there could be no doubt as to their authenticity, but if you are willing to finally make this public (especially if it came from reasonable and honest developers, that doesn't include you or theo), i am willing to give you (the developers) the benefit of doubt - deal?

          Comments
          1. By djm () on

            1. "So now that you admit to not knowing, you can stop casting wild aspertions."
            what are you talking about?

            I'm quoting you: what you missed in your post is that the core of the problem is not whether OpenBSD invented stuff independently or not, but that we (and you) simply don't know.

            See http://www.deadly.org/commentShow.php3?sid=20031009110855&pid=1588

            Comments
            1. By Anonymous Coward () on

              And you *still* didn't answer any of his questions!

              You are a joke, Damien Miller.

            2. By Anonymous Coward () on

              And you *still* didn't answer any of his questions!

              You are a joke, Damien Miller.

            3. By PaX Team () pageexec at freemail.hu on mailto:pageexec at freemail.hu

              ok, if that's what you referring to then you should explain the second part: "stop casting wild aspertions [assertion?]". what assertions of mine are 'wild' (presumably meaning 'wrong' or 'not justified')?

          2. By djm () on

            - can you make them public, if not, why not?

            You ignore what I said: if any of us were to make our communications public (and I don't have the right to release any but my own) - we could easily be accused of hiding things. There is no way to refute this, so why even start down that road?

            Anyway, what right do you have to demand access to private conversations? I demand that you post your inbox to the web first. (See how ridiculous a proposition this is?)

            please answer the question of why said development process is not public at all

            What, like the public CVS tree (the first among free software projects IIRC), the source-changes@ mailing list or the public bug tracker? That is a pretty public development process. Anything more is reserved for people who contribute patches rather than accusations.

            I won't waste any more time arguing with you BTW. I wasn't involved with the development of any of the memory protection tricks (they were done by smarter people than I), but it frustrates me to see honest, dilligent developers, who donate their time and work under the most liberal of licenses accused of plagarism. Your carping accusations damage yourself and your project. This is a much bigger shame than you seem to realise.

            Comments
            1. By PaX Team () pageexec at freemail.hu on mailto:pageexec at freemail.hu

              1. "You ignore what I said: if any of us were to make our communications public (and I don't have the right to release any but my own) - we could easily be accused of hiding things. There is no way to refute this, so why even start down that road?"

              nice try but you failed to read when i said that i would give you the benefit of doubt were the honest among you make these public. second, you put yourself into this situation by having kept said development process private, it's *your* decision and problem. third, i was not asking for *private* emails, where did i say that? once more, don't put words into my mouth i have not said. on the other hand you *still* didn't answer the question:

              are there non-public (secret) discussion lists/etc in your development or not?

              since you have a tendency of misreading things, i will spell it out more clearly: i'm referring to mailing lists, newsgroups, icb/irc channels and the like which can/could be made public, i did *not* ask about private mails (although i'd certainly appreciate them as well if they contain interesting info and the parties involved agree to their publishing).

              2. "What, like the public CVS tree (the first among free software projects IIRC), the source-changes@ mailing list or the public bug tracker? That is a pretty public development process."

              these are the public records of the source code changes, they are *not* the public records of your development process which involves a few more steps before it gets to committing code, among others discussions about the design, cost/benefit of solutions, etc (need i really point you to the apparent differences between lkml and tech@ for example?). i thought you had known that much and had figured that's what i was interested in. and before it begins to sound too personal, it's not only me who is interested in knowing what goes on 'behind the scenes' (how can a supposedly 'open' project keep these important discussions private anyway?) but many others including your own users (i wish more of them spoke up every now and then).

              3. "Anything more is reserved for people who contribute patches rather than accusations."

              can i take that as the official opinion of the OpenBSD project? if so, you guys can blame only yourselves if people have to substitute hard facts with their speculation (or more, as the case may be). it's your choice to be open or not, bear with the consquences of your decision then.

              4. "but it frustrates me to see honest, dilligent developers, who donate their time and work under the most liberal of licenses accused of plagarism. Your carping accusations damage yourself and your project. This is a much bigger shame than you seem to realise."

              if you read just this thread (or earlier bugtraq/misc@ ones) you will see how 'honest' some of these developers are/were - were you in my position, i bet you'd be less keen on trusting such guys on their word either, i at least decided not to. it's interesting that you talk about damage but misplace it on the wrong project and people - you yourself point out that my sole 'accusation' is my desire to know what really happened, that's hardly damaging to me, but your utter silence/ignorance has already put you into a very tricky situation.

              ps: public domain is more liberal but let's not digress ;-)

              ps2: the number sqrt(2) can be shown to be irrational, that's a negative proof (there's no p/q that equals to it)

              Comments
              1. By djm () on

                Like I said, I'm not going to continue to argue, except to add:

                1. I speak only for myself

                2. A negative proof is not the same thing as trying to prove a negative. (I prefer the negative proof that there are an infinite number of primes, myself)

                Comments
                1. By Anonymous Coward () on

                  Apparently math isn't your gift. There are a finite number of mails in your archive. Thus, by a grep as was demonstrated, you CAN PROVE that you legitimately developed the ideas for W^X GET IT?

                  Comments
                  1. By djm () on

                    Apparently literacy isn't your gift. I have said a number of times that I didn't develop W^X or any of the other memory protections in OpenBSD.

                    Anyway, are you willing to open your mailbox to inspection by random people? Judging by the fact that you refuse to identify yourself when making accusations, I'd guess not.

                    Comments
                    1. By Anonymous Coward () on

                      What does that have to do with it? The question was: does OpenBSD have private development mailing lists? If so, could you grep for PaX in them, and just tell the PaX team the date of the matches. What does any of this have to do with you not developing W^X?

                      I don't need to open my mailbox to random people, since I have nothing to prove. OpenBSD does.

                      Comments
                      1. By Wim Vandeputte () wim@kd85.com on http://kd85.com/

                        This argument is a bit flawed as there are quite some messages that give false positives, man 1 pax for a change...

                        Comments
                        1. By Anonymous Coward () on

                          And of course this applies to the correct capitalization PaX. Of course it would be impossible to tell from context which was being talked about. Give me a break.

                      2. By henning () henning@ on mailto:henning@

                        if that makes you happy, I did the grep.
                        lots of matches for the userland utility pax(1).
                        first match for your PaX is in 2003 with the first mails from PaX advocates to public mailing lists.

                    2. By Anonymous Coward () on

                      I'm sure you are aware "you" can be used in the plural sense, as it was in this case, to refer to the collection of OpenBSD developers (particularly those involved with W^X). Don't comment on my literacy when you can't read yourself.

                      Comments
                      1. By Ulysses () on

                        well, use 'OpenBSD developers (who were involved in the development of W^X)' instead of 'you' then. Your reply to djms post didn't come through the way you obviously wanted it to do.

                  2. By Can Erkin Acar () on

                    Apparently math isn't your gift. There are a finite number of mails in your archive. Thus, by a grep as was demonstrated, you CAN PROVE that you legitimately developed the ideas for W^X GET IT?

                    And apparently logic is not your gift. Here is a scenario none of the PaX team has considered:

                    Assume you have a finite number of documents, collected from the 'secret archives (tm)' you ran grep and weed out the false positives. To find only the discussion about the recent flamewars and such, and no previous discussion or mention of PaX.

                    Now what?

                    1. you start demending more searches for other strings such as 'random' 'no exec' 'stack' and other nonsense trying to prove your point.

                    2. You conclude that there must be more 'secret documents' hidden from you and demand developers inboxes, hard drives, CD-ROM archives, MP3 players, encryption keys for any encrypted content etc.

                    3. repeat ad infinitum ...

                    And we were glad we got rid of DARPA.

                    Please, there is a point where such demands turn into harassment. You have already judged people you barely know to be dishonest (including djm, which you proclaimed dishonest immediately after learning that he is a developer) and this is starting to turn ugly.

                    And by the way, please send me the contents of your harddisk. I have some strings to grep for. Yes, this is a legitimate demand, does the PaX team not have an open development process?

                    Comments
                    1. By Anonymous Coward () on

                      Apparently you didn't read the comment from the PaX team that if PaX was not mentioned in the mailing list archives, they would give OpenBSD the benefit of the doubt. Quit making stupid excuses.

                      Also, shut the fuck up.

                      Thank you.

                      Comments
                      1. By Can Erkin Acar () on

                        No one really cares about the judgements and doubts of the PaX team.

                        You are not in a position to actually demand anything. OpenBSD developers are not accountable to you. You have already asked, and got your answers.

                        It is simply not possible to prove what you are asking, even if the privacy of the individual OpenBSD developers are violated extensively.

                        Accept it and go home, do something constructive for a change. Develop PaX, to make it even better. Do some research, compare PaX and W^X and publish your results so that everyone can benefit. Discuss the differences and implementations without resotring to accusations and flamewars.

                        And if these publications or discussions result in an improvement in W^X or PaX, be glad that the overall security of the internet is improved.

                        Thank you.

                        Comments
                        1. By Anonymous Coward () on

                          Hey worthless piece of shit, how about YOU go and do something constructive instead of giving your ignorant opinion that nobody cares about?

                          Apparently Theo cares about the judgements of the PaX team, otherwise he wouldn't be going to Japan to make an ass of himself in front of everyone.

                          Hooray for Theo! He's done more to discredit his own project than anything I could ever do.

                          Comments
                          1. By Can Erkin Acar () on

                            And you dont have to go to Japan to make an ass of yourself. You are doing fine here already.

                            Comments
                            1. By Anonymous Coward () on

                              At least I'm not wasting your money and the money of everyone in attendance to do it.

                              Comments
                              1. By Anonymous Coward () on

                                Actually, you are. Think this internet connection is free?

                      2. By Anonymous Coward () on

                        if it makes you feel better, in a previous thread, henning@ posted:

                        ------------------------
                        if that makes you happy, I did the grep.
                        lots of matches for the userland utility pax(1).
                        first match for your PaX is in 2003 with the first mails from PaX advocates to public mailing lists.
                        ------------------------

                        now, he has done what you asked, so if you continue to troll, thats your choice.

                2. By krh () on

                  > 2. A negative proof is not the same thing as trying to prove a negative. (I prefer the negative proof that there are an infinite number of primes, myself)

                  Well, I happen to be a mathematician, the term `negative proof' is ambiguous, and I have free time. So:

                  `Proving a negative' is not a very well-defined term in formal logic, because statements don't necessarily have well-defined positive or negative orientations. Nevertheless there is a method called proof by contradiction which lets you prove the irrationality of sqrt(2) and the infinitude of the primes. Proof by contradiction works like this: I am given as a true fact some true statements, called axioms, and the knowledge that some proposition P is true (P might be an axiom, but it mught also be a true statement derivable from the axioms). I would like to prove that proposition Q is true. If Q is not true, then by the law of the excluded middle, it is false. So I will assume for the moment that Q is false, and using that assumption I will show that P is also false. But I know that P is true, and by the assumption of consistency, P cannot be both true and false. So I have reached an impossibility: A system where no proposition can be both true and false, but P is both true and false. Therefore one of my assumptions is wrong. This is either one of my axioms or my assumption that Q was false. Therefore one of these is wrong. Thus if I continue to assume the same axioms I started with, Q must be true.

                  When most people talk about proving negatives, this is not what they mean. What they mean has to do with constructively proving statements of non-existence. `Constructively' means that you have shown the existence of the object you are considering (your object here can be geometric, arithmetic, logical, etc., just so long as you have produced an example of it). In a philosophical sense, it involves no tricks; you know that the things you have proved to exist do exist because you found them. This is where the name of this philosophy, `constructivism', comes from: You construct things.

                  Here you run into a very hard problem: If something doesn't exist, how do I construct its non-existence?

                  I don't happen to be a logician, and I'm not much interested in constructivism, so I don't happen to know how constructivists deal with non-existence, or even if they can. At the least it looks to me like a very difficult problem unless the set of all possibilities is finite (which you need to show constructively, of course). And this is why you can't prove a negative in the everyday sense: In that sense of the phrase, it means to constructively show non-existence. If the set of all possibilities is infinite, or effectively infinite, and you have to search through every single one to show that something doesn't exist, you lose.

                  Having said that, let me give a non-constructive proof that is not by contradiction. I will show that there is a real number r such that r^(sqrt(2)) is a rational number.

                  If sqrt(2)^sqrt(2) is a rational number, we're done. Otherwise (sqrt(2)^sqrt(2))^sqrt(2) = sqrt(2)^(sqrt(2)*sqrt(2)) = sqrt(2)^2 = 2 is rational.

                  This proof is not by contradiction, but it doesn't construct the number r that we're looking for. r is either sqrt(2) or sqrt(2)^sqrt(2), but we don't know which, so the proof is not constructive.

                  Comments
                  1. By Anonymous Coward () on

                    You don't have to be a dumbass mathematician like yourself to know that the text in their archive is finite, and easily searchable via grep.

                    BTW, your proofing techniques are like that of a beginner. Are you a mathematician of high school?

                    Comments
                    1. By krh () on

                      I feel somewhat embarassed. I know I'm supposed to feel insulted, but instead I laughed out loud at your comment. Yes, of course I know that their archive is finite and easily searchable via grep. I also know that grep just searches for regular expressions; it doesn't understand the text it's looking for, and it's easy for you to claim that the OpenBSD project hid its supposed use of PaX by some trick. Then you can claim the right to more information, and so on, until the amount of information you've requested is so large it's effectively infinite, and thus impossible to satisfy.

                      No, I am not "a mathematician of high school". I happen to be a mathematician of graduate school, i.e., I am a graduate student, and, as anyone with any experience would have noticed, not a beginner. I suspect that your "proofing techniques" are much less advanced than mine.

                      May I suggest that you read Walter Rudin's _Principles of Mathematical Analysis_? It was the first advanced math book I ever read, some six years ago, and I admire it very much for its clear exposition (though it is occasionally a little unmotivated, and the differential forms chapter is no good). Also, I suggest that you find a copy of the second edition, probably in a math library somewhere, and read its first chapter before proceeding to the first chapter of the third edition. In the first chapter of the third edition he relegates the construction of the real numbers to an appendix since he found that it was too difficult for many people taking an introductory course in real analysis. I didn't have that sort of difficulty, and I think that the construction of the real numbers is so important for such a course that it should be the first topic covered, just as he has it in the second edition.

                      If you're not much of an analyst, you could always try Hungerford's _Algebra_, which has always been my favorite abstract algebra textbook. It is a graduate textbook, but it is self-contained, and its succint exposition let me use it very productively as an undergraduate. However I should warn you that it's a bit dense. This might make it a perfect match for you, however, so you'll have to try it yourself.

                      Good luck. Maybe someday, if you ever make it to graduate school, I'll be your advisor.

                      Comments
                      1. By Anonymous Coward () on

                        an advisor of how to be an elitist prick 101 ?

                        Maybe someday, you'll have some friends that give a fuck about everything you've just said. I got bored after reading the first few sentences and stopped.

                        Comments
                        1. By SH () on

                          Ah, how tiresome some of you immature PaX advocates are, and I wonder how the PaX community can tolerate the likes of you.

                        2. By krh () on

                          It's poor style to admit that you won't listen your opponent's argument. At least when you were flaming other people, you tried to act like you were replying to them. As it is, I can rightfully claim I've won, because you didn't understand what I was saying.

                          And as long as I'm baiting you, I should mention that you're going about this in entirely the wrong way. Correct me if I'm wrong here, but you're trying to make people mad by posting anonymously in a public forum, yes? But it's not really working, you see, because there's just not enough people here to really get pissed off. You need to go for the gold: Slashdot. I'm serious. You can't claim to be a real troll until you've started a month-long, ten thousand post flamewar on Slashdot. Until you can do that, I just can't give you any respect. I mean, it used to be that you could claim to be a good troll if you could get a few groups on Usenet to broil each other--heck, that's how a lot of people got started--but Usenet's like that all the time now, so it's not like you could claim to be doing anything disruptive.

                          So until you can troll Slashdot and troll it well, you won't have the skillz to make me do anything but laugh.

                          HTH, HAND.

            2. By Anonymous Coward () on

              Did you not see that you don't have to provide any of the conversations? How does a grep of PaX through your icb logs and private mailing list archives disrupt the secrecy that you are trying so hard to preserve?

          3. By Anonymous Coward () on

            • have you got developer discussions and logs that are not available to the public?
            • can you make them public, if not, why not?
            Of all my lurking and being a (l)user the funniest thing hit me in the head. From what little I've read, you've already been told. Be realistic here, how likely is there going to be a 'recording device', audio or otherwise when you are sitting around /w collegues having a beer and bantering back ideas on how to improve product? Do you really think that the first step in the hack-a-thon (not that I've been to one, cause I highly doubt I would be able to contribute on a technical level) is to document the process of before starting to work, especially in such a limited amount of time?

            I hate to break it to ya, your not likely going to find one.

  14. By Anonymous Coward () on

    http://www.netsys.com/openbsd-misc/1999/12/msg00873.html

    Read that hilarious thread and then think that Theo claims to have developed the entire idea of W^X shortly after. One day it's really really hard, and the next he's magically solved every problem by himself? That's pretty incredible stuff, folks!

    Comments
    1. By Joris () on

      Learn to read,

      "We've just never written code to protect the stack, because that's really difficult"

      difficult != impossible so whats wrong with finding the answer the next day or the next week? Some people learn every day so stop whining.

Credits

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 deadly.org 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.]