Forgot your password?
Security Operating Systems BSD

OpenBSD Will Not Fix PRNG Weakness 196

Posted by kdawson
from the random-acts-of-kndness dept.
snake-oil-security writes "Last fall Amit Klein found a serious weakness in the OpenBSD PRNG (pseudo-random number generator), which allows an attacker to predict the next DNS transaction ID. The same flavor of this PRNG is used in other places like the OpenBSD kernel network stack. Several other BSD operating systems copied the OpenBSD code for their own PRNG, so they're vulnerable too; Apple's Darwin-based Mac OS X and Mac OS X Server, and also NetBSD, FreeBSD, and DragonFlyBSD. All the above-mentioned vendors were contacted in November 2007. FreeBSD, NetBSD, and DragonFlyBSD committed a fix to their respective source code trees, Apple refused to provide any schedule for a fix, but OpenBSD decided not to fix it. OpenBSD's coordinator stated, in an email, that OpenBSD is completely uninterested in the problem and that the problem is completely irrelevant in the real world. This was highlighted recently when Amit Klein posted to the BugTraq list."
This discussion has been archived. No new comments can be posted.

OpenBSD Will Not Fix PRNG Weakness

Comments Filter:
  • by Anonymous Coward on Sunday February 10, 2008 @09:05AM (#22368958)
    if you think its a problem, exploit it
    nothing says "fix it" faster than a few thousand compromised hosts
    release a PoC that gets r00t, inform the security lists and stand back
    thats what full disclosure is for.

    if it isnt exploitable then BSD can fix it at leisure
    or if thats not quick enough and as its Open Source, YOU fix it if you are that concerned

    now somebody call the whhaaambulance
    • by Jugalator (259273) on Sunday February 10, 2008 @11:08AM (#22369650) Journal

      if you think its a problem, exploit it
      • by Jugalator (259273) on Sunday February 10, 2008 @11:10AM (#22369674) Journal
        Wow, Slashdot ate my whole comment besides that link... A bug?

        Anyway, besides rudely just posting a link like that in response, I was going to say that proof-of-concept code has at least already been published, and his point is that FreeBSD, NetBSD, DragonFlyBSD has fixes available. Apple is currently working on a fix for OS X. OpenBSD is not planning to fix this. More info can be found in my parent link.
        • Re: (Score:2, Insightful)

          by alexhs (877055)

          Wow, Slashdot ate my whole comment besides that link... A bug?
          A bug indeed, and it is yours, apparently you can't code in HTML :P
          You probably did a typo in a closing tag. Anyway, There's a reason why we have a "preview" button ;)
  • Uh what (Score:4, Insightful)

    by Brian Gordon (987471) on Sunday February 10, 2008 @09:05AM (#22368968)
    Is the summary just supposed to be as shocking as possible? How about some details on why specifically they decided not to patch it?
    • Re: Uh what (Score:5, Informative)

      by Dolda2000 (759023) <fredrik@dolda2000 . c om> on Sunday February 10, 2008 @09:24AM (#22369048) Homepage
      I'm no security expert and I don't know anything about the attack vectors that he claims, so maybe I shouldn't say too much, but I do know this: TFA mentions that the PRNG is used for such fields as DNS transaction IDs and IP header fragment IDs, and these fields were never even meant to be random from the beginning. Verily so, TFA even says that {Free,Net}BSD don't even use the PRNG by default, but uses sequential numbers unless a certain sysctl is tweaked.

      Thus, it is my guess that even if the attack vectors are deemed serious enough, the OpenBSD team has decided that it doesn't matter, since these protocols were never designed for security anyway, and that one should use DNSSEC and/or IPSEC (or TLS) if one actually wants to be secure (it does raise the question as to why they decided to use a PRNG for those fields from the beginning, though). My second guess is that they don't even consider the attack vectors serious, though, since they probably require a cracked router to be effective anyway.

      Indeed, if they do require a cracked router, then I don't see the issue to begin with. One of the attacks was that the attacker could inject data into a TCP stream and such things, and if he has a router cracked, then I'm pretty sure he could forge all the data he wants anyway, without using any particular software attack at all, and likewise with DNS data.

      • Re: (Score:2, Informative)

        by Anonymous Coward
        The idea behind the suggested attack vector is to find a way of sending matching packets *without* sitting in the path of the data. If you can guess certain values which the server will send to other hosts with a high probability and do so just by looking at packets which the server sends as answers to your requests, then you can spoof packets and other hosts will accept your misleading payloads as though they were coming from the server.
        • by Dolda2000 (759023)
          Really? If that is truly so, then I'd argue that that is what is the actual security flaw, and not the non-randomness of the IDs. For sure, you won't be able to carry out any of the IP attacks that way, since fragment IDs are local to the sending host. To be honest, I didn't understand how the DNS vulnerability worked to begin with (I didn't see it being explained anywhere), so I can't make any statements about it, though.
      • Re: Uh what (Score:5, Informative)

        by Smallpond (221300) on Sunday February 10, 2008 @10:57AM (#22369574) Homepage Journal
        The reason that they weren't designed to be secure is that noone had thought of the "DNS poisoning" attack when the protocols were designed. If they had, they would have made the ID field longer. Since it is only 16 bits, I doubt that there is any very secure way of protecting someone from guessing the next value. The paper describes a method of narrowing it down to 8 possibilities by doing ~10^9 calculations.

        The exploit described in the paper doesn't require a cracked router, just a malicious website. Once you can inject fake DNS entries for or on some ISP's DNS server, the exploit has paid for itself.
    • Re:Uh what (Score:5, Interesting)

      by Zeinfeld (263942) on Sunday February 10, 2008 @09:25AM (#22369050) Homepage
      Is the summary just supposed to be as shocking as possible? How about some details on why specifically they decided not to patch it?

      It is entirely believable to me. Back in 1995 I told Marc Andressen at Netscape that he had a serious problem with the random number generator used to choose session keys for SSL. There was simply not enough randomness going in for there to be 128 bits going out.

      Marc had every reason to listen to me, I had broken SSL 1.0 in ten minutes when he tried to demonstrate it at MIT. But it took several weeks to drill the problem into his thick skull.

      So they eventually asked me for a description of how to do the thing right.

      A year later the exact same bug was discovered independently. By this time they had hired some competent crypto people. I spoke to Taher about the problem later and his explanation was that they found the design note on the PRNG which was so comprehensive that they didn't think it necessary to check the actual code.

      • Re:Uh what (Score:5, Funny)

        by fulldecent (598482) * on Sunday February 10, 2008 @11:13AM (#22369716) Homepage
        You cracked Marc's 128-bit encryption, but your Slashdot id is 263942. Doesn't add up.
        • Re:Uh what (Score:5, Funny)

          by LizardKing (5245) on Sunday February 10, 2008 @12:51PM (#22370468)

          That's because he's so l33t he can pick a Slashdot id at random every time he posts.

        • Re: (Score:2, Informative)

          by Anonymous Coward
          Zeinfeld, aka Phillip Hallam-Baker is the CTO of Verisign, and while he occasionally makes outlandish claims about himself and his past on Slashdot, most of those claims are well-grounded in reality.

          On SSL/TLS and similar security/crypto issues, he is always interesting and more likely to be right than not.

          On supporting large scientific computing platforms, he is always interesting and more likely to be right than not. His system administration c.v. is impressive.

          On interpreting the experiments performed
        • by gatzke (2977)
          Low slashdot id doesn't mean much. They used to give accounts to anyone...
          • Re: (Score:2, Funny)

            by Anonymous Coward
            They used to give accounts to anyone...

            ...and their standards have declined over time :)
        • by toriver (11308)
          Maybe he has spent his time working and learning instead of wasting it on Slashdot?
        • Re: (Score:3, Informative)

          by Zeinfeld (263942)
          You cracked Marc's 128-bit encryption, but your Slashdot id is 263942. Doesn't add up.

          Marc's 128 bit encryption used a random seed with 24 bits worth of ergodicity. So it was only 24 bit secure.

          And SSL 1.0 had no integrity protections whatsoever, which would have been pretty bad even if he wasn't using a stream cipher. So even if he used a 256 bit cipher it would have been broken.

          What makes you think this is my only Slashdot id?

          Oh and in response to the AC in the other thread, no my job title is not

    • I have noticed that people are complete and utter idiots about two very important cryptographic algorithms. PRNGs and hash functions. I can't believe the number of people who still use a simple MD5 hash for software download verification. First, it isn't signed, so all someone has to do is alter both the hash and the code. Secondly, even if it were it's not very hard to make two pieces of code, one innocuous and one malicious that both have the same MD5 hash, and it's been true for years.

      DNS cache pois

      • by RT Alec (608475)'s not very hard to make two pieces of code, one innocuous and one malicious that both have the same MD5 hash, and it's been true for years.

        I'm calling you on this claim.

  • by Anonymous Coward
    DNS cache poisoning []
  • OpenBSD secure?! (Score:4, Interesting)

    by darkob (634931) on Sunday February 10, 2008 @09:21AM (#22369032)
    This most certainly WILL have impact on OpenBSD's status as "secure" OS. Indeed, OpenBSD claims to have "proactive" approach towards security whereas this issue should and will diminish some of the OpenBSD's "security goodwill".
  • Oh for Bob's sake! (Score:2, Insightful)

    by Chas (5144)
    When the PRNG in WINDOWS is shown to be vulnerable (because it's a actually static value), it's a horrendous problem.

    But when the PRNG for a non-MS operating system is shown to have a similar (but not identical) problem, it's "irrelevant"?

  • It is not just good enough to be 'secure in the "real world"' it is also important to be seen and believed to be secure.

    Can someone say how hard a fix would be ? Surely: for the sake of a bit of work they are committing a public relations blunder!

  • I am sorry for this vague subject, but I can't remember the exact topics or incidents anymore, but there were numerous even mentioned on slashdot.

    But I wanted to show that most of todays security threats
    were first percived hard to be used or totally unthinkable, even minor security problems
    which later were updated to the status of a serious threat, because the first look turned out to be wrong.

    So when devellopers commit themselves to build the most secure OS, and than on the other hand show such no-interest
  • Strike 2, OpenBSD. (Score:5, Insightful)

    by Neillparatzo (530968) on Sunday February 10, 2008 @10:17AM (#22369334)
    OpenBSD is on a fast track to losing its most favored secure OS status if they keep this up.

    First they refused to implement WPA (despite the other BSDs having it), because it "doesn't provide real security" and "just use IPSEC".

    Now they're refusing to address a weakness in their network stack (despite the other BSDs addressing it), again with the implication that everybody should just jump to IPSEC. What if you're in a situation where an IPSEC rollout is impractical or impossible?

    Whatever happened to defense in depth? Whatever happened to "secure by default"? Whatever happened to constructive paranoia, such as randomizing of libc addresses, that was unlikely to have any real impact on security but was a nice extra, just in case? Why must I now upgrade to NetBSD to get security features that are lacking in OpenBSD? Isn't the shoe on the wrong foot?

    What happened? Was there a change of management? Is OpenBSD under the thumb of a douchebag patch manager lately? Is this going to go away at some point? Those of us that sleep with OpenBSD firewalls like a gun under our pillow are taking notice.
    • Re: (Score:2, Insightful)

      by the_B0fh (208483)
      And they care about your notice why?
    • Re: (Score:3, Insightful)

      by Anonymous Coward
      First they refused to implement WPA (despite the other BSDs having it), because it "doesn't provide real security" and "just use IPSEC".

      Umm, they're completely correct to take this stance. WPA is far inferior to IPSEC, security-wise. It's OpenBSD's job to help insulate you from insecure technologies. We could easily say, "Just because FreeBSD allows one-character passwords, OpenBSD should, too!" And you know what? We'd be wrong to think in that way.

      What happened? Was there a change of management? Is OpenBSD
      • by Anonymous Coward on Sunday February 10, 2008 @02:33PM (#22371448)
        IPSec is OSI layer three, WPA is layer two. Accordingly, they are not substitutes for each other; they are compliments.

        So, OpenBSD is refusing to put a locking mechanism on the doorknob because it wants to make people use a deadbolt. Me, I'd want both; if it turns out my deadbolt had a defect and thus easily defeated, the doorknob lock would at least provide some security.
    • Theo has refused to implement other 'foreign' security changes in OpenBSD when they were first introduced, then turned around and implemented them after a while. He was contemptuous towards non-execute stacks when I spoke with him at Usenix many years ago, because he was convinced OpenBSD's code review policy made it irrelevant and because no-execute didn't stop all stack smashing attacks... but OpenBSD eventually picked it up.

      Basically, he's very conservative, very resistant to change, and don't forget that's one of the things that made OpenBSD what it was to begin with... but if it really matters he'll come around.
    • Re: (Score:3, Interesting)

      by styrotech (136124)

      First they refused to implement WPA

      From my impression that is an overstatement. OpenBSD will get WPA when someone writes it well enough for it to get in. Although the current devs don't want to write it themselves (as they don't feel they need it), they have left the door open for someone else to write it.

      "doesn't provide real security" and "just use IPSEC" aren't reasons why it won't get in at all but reasons why that particular developer(s) isn't going to bother writing it themselves. OpenBSD is probably

    • Re: (Score:3, Interesting)

      It isn't that they just flippantly refuse these things to be assholes, they have extremely limited resources and they have to make tradeoffs.
    • But they tend to have a point. They are right, ultimately, that the transport level is the "correct" level for security. WEP and WPA are both, ultimately, kind of pointless in that a determined attacker will be able to compromise them. It's just that WPA prevents a large class of casual attacks that WEP doesn't. In theory, yes, someone concerned about secure network traffic will secure that traffic at the transport level -- the problem is that if you don't control both sides of the transaction, transport-
  • "OpenBSD is completely uninterested"

    What you really mean is 'Theo doesn't use this feature, so it cant possibly be important to anyone else in the world'. OBSD is a one man show.
  • PRNG is used mostly by people who don't have a random number generator. PRNG is not needed by most (all?) current Unices and Linux distributions as they have a random number generator at /dev/random and /dev/urandom. Even older versions of Unix have patches that add a random number generator.
    • Re: (Score:3, Interesting)

      by ivan256 (17499)
      Where do you think the data for /dev/urandom comes from? It's a pseudo-random number generator unless you've got a hardware random number generator, but even that probably uses a pseudo-random algorithm.
      • Re: (Score:3, Informative)

        Where do you think the data for /dev/urandom comes from? It's a pseudo-random number generator unless you've got a hardware random number generator

        It's my understanding that urandom often uses data from interrupts, keyboard input, device controllers etc. to increase the entropy of the random numbers it produces.

        hardware random number generator, but even that probably uses a pseudo-random algorithm.

        Hardware random number generators are not considered pseudo-random. As I understand it they usually ampli

  • by davidbrit2 (775091) on Sunday February 10, 2008 @12:15PM (#22370206) Homepage [] Oh hush, you knew somebody would post it.
  • Question for the cryptography slashdotters out there. I have only a superficial and mostly layman's knowledge of cryptography, so while I understand the need for random numbers exists, I don't know much about how they are created or used. I'm not clear on how it is possible for a digital machine, particularly a commodity hardware machine, to create random numbers that form the basis of seeds or simple one-time pads. It is my impression that any mathematical algorithm you can run in software is potentially g
    • by SEE (7681)
      If you use the Via x86 processors, they have a genuine hardware RNG built in (which seems to be based on thermal noise), and you can buy true RNG peripherals. But pretty much nobody uses them (Via chips are too slow, peripherals are an added expense), which means most systems have to default to PRNGs (because it's marginally cheaper).
    • People have done things like adding randomness via microphone noise, but I'm not really sure how reliable that is.

      The rest of it either isn't necessarily random, or isn't necessarily cheap enough / fast enough. And PRNGs can be made hard enough to guess that no one will. It's kind of like how RSA is possible to crack, if someone guesses the right prime factors, but with a sufficiently large key size, you can get to where all of the matter in the Universe, assembled into chips that vaguely resemble today's p
  • But it gets more interesting. Several other BSD operating systems
    copied the OpenBSD code for their own IP ID PRNG, so they're
    vulnerable too. This is particularly so with Apple's Mac OS X,
    Mac OS X Server and Darwin, but also with NetBSD, FreeBSD and
    DragonFlyBSD (the 3 latter O/S however only use this PRNG when
    the kernel flag net.inet.ip.random_id is set to 1; it is 0 by
    default, resulting in a sequential counter to be used instead...).

    This is really a ways out of my depth, but my naive understanding is that the PRNG is a problem because it is not actually random, and can therefore be predicted. Yet, the above states that the other BSDs in particular don't even use the randomization by default, and instead use the most predictable sequence possible. Am I missing something, or doesn't that mean the other BSDs are significantly more at risk (for whatever value of 'at risk' this threat actually corresponds to)?


  • by m.dillon (147925) on Monday February 11, 2008 @12:27PM (#22380014) Homepage
    After the Nth time someone as approached me talking about flaws in BIND's random number generator I just have to ask myself, why the hell do the bind people, with no real cryptographic knowledge, think they can write their own? Bind doesn't seem to even have an option to use the OS's PRNG.

    I had an interesting discussion with Amit regarding all the hacks people (including the Bind people) do to try to roll their own random number generator and it prompted me to review our own IP randomization code (and the 'off' default). After review I was decidedly uneasy about its secureness, mainly because it was trying to use an algorithmically generated cycle for a tiny namespace (16 bits, actually 15 the way it was coded). The problem with the IP sequence space is that you can't just randomize it, you also have to ensure that sequence numbers are not immediately repeated. DNS has similar issues.

    I gave up trying to improve the algorithm and decided to throw in the towel and allocate 128KB of memory to do a look-ahead running shuffle of the 65536 possible sequence number using the system's PRNG. It's not possible to do better then that, frankly. We also decided to turn on ip randomization by default.

    So that brings me back to the question: Why the hell doesn't bind have an option to use the system PRNG? Not all systems have a good random number generator, but I trust ours far more then the junk coded into bind. For that matter, I don't really mind if bind ate another 128K of memory to secure its own sequence space, if that is what it takes.

    I know enough about cryptology to know that I am not a cryptographer. But regardless of that, I can still get a good feel for someone else's code and what BIND does scares me. The y need to change their code to default to something more secure, even if it is memory intensive. If they want to give their users the option to use the less memory intensive algorithm that's fine with me, but the default needs to be more secure.

    DNS has its own design issues, but that is no excuse for software to exasperate them.


panic: kernel trap (ignored)