OpenBSD Will Not Fix PRNG Weakness

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

Comments

then exploit it (if you can)

[Anonymous Coward]

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

Re:then exploit it (if you can)

[digitig]

If you're working at the level where a friend has to explain the weaknesses in a PRNG class, one you roll yourself is highly unlikely to be better. There are many algorithms out there that have been very thoroughly analysed and explored by experts, and there's going to be one out there that's easy to find and better than your hand-rolled one. And, of course, what count as "weaknesses" depends on the application. A PRNG that's great for Monte-Carlo simulation may be too predictable for cryptography. A PRNG that's sufficiently hard to predict for cryptography may be too slow for Monte-Carlo simulation.

Re:then exploit it (if you can)

[maxwell demon]

Kinda hard to make some if nothing in our world are truly random. Or is anything?

Quantum mechanics delivers true randomness, at least according to the standard interpretation.

Re:then exploit it (if you can)

[Jugalator]

if you think its a problem, exploit it http://www.securityfocus.com/bid/27647

Re:then exploit it (if you can)

[Jugalator]

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:then exploit it (if you can)

[orgelspieler]

I wrote a program like that once. It kept on outputting 42.

Re:then exploit it (if you can)

[maxwell demon]

Well, let me try to explain.

Imagine a spin-1/2-particle (e.g. an electron). Such a particle has the peculiar property that if you measure its spin along any chosen axis, you'll always get either 1/2 ("spin up") or -1/2 ("spin down").

OK, let's assume we have just measures the spin in z direction and got +1/2. Let me first note that this is stable: If we measure the z-spin of the same particle again (assuming it didn't interact in between), we will again get +1/2 each time. That is, once we measures +1/2 in z direction, every subsequent measurement will confirm that result (this may seem trivial, but it will be important further down).

Now we want to know: What is the spin in x direction? Well, it can neither be 1/2 nor -1/2, because we've "used up" all of the spin for the z direction. OTOH +1/2 and -1/2 are the only allowed values; 0 is not a possible value.

But then, if we want to know the spin in x direction, after all we can just measure it. If we do so, we indeed find either +1/2 or -1/2, and never anything else. Moreover, we find that in half of the cases we get +1/2, and in the other half we get 1/2, so on average the x spin indeed is zero, but for each single measurement we get either +1/2 or -1/2. And that value also turns out to be stable: If we repeat the x-spin measurement, we get the same value again.

Well, now we could say, maybe we just got all wrong about spin, and in truth electrons have separately an x spin of +1/2 and -1/2 and a z spin of +1/2 or -1/2 (and the same for any other direction), and what we've found is just that half of our electrons are electrons with "+" spin in one direction, and "-" spin in the other. Now, let us test that hypothesis.

We now only look at electrons which were found to have spin +1/2 in z-direction, and subsequently found spin +1/2 in x direction. OK, if the above hypothesis holds, if we now again measure in z-direction, we should again confirm the value +1/2, because after all, that value is stable, right? Well, what we find is that only in half of the cases we find z-spin +1/2, but in the other half we find z-spin -1/2! So somehow by measuring the x-spin, we destroyed the value for the z-spin.

Indeed, by measuring the spin value in one direction, we destroy the spin value for any other direction. The latest measurement destroys all information gained through previous measurements, so that if we know what we measured last (i.e. both the direction we measured in, and the measurement result), we know everything we can know about the spin. The results of previous measurements don't add any knowledge about future measurements. If we measured +1/2 on one measurement, the probability to get +1/2 on another measurement depends only on the angle of our new measurement direction to the previous measurement (and the same of course for -1/2). The smaller the angle, the more probable is it top get the same result for the new direction (measuring again in exactly the same direction reliably gives the same result again, as noted above). If we measure in a direction perpendicular, the results are completely uncorrelated to the previous measurement result; we get just +1/2 or -1/2 with 50% probability each.

So measurement obviously destroys whatever state the electron spin had before, and establishes a new state according to the result we got.

Uh what

[Brian Gordon]

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

[Dolda2000]

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:Uh what

[Zeinfeld]

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

[Smallpond]

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 bankofamerica.com or ebay.com on some ISP's DNS server, the exploit has paid for itself.

Re:Uh what

[fulldecent]

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

Re:Uh what

[LizardKing]

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

OpenBSD secure?!

[darkob]

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

Re:So much for high security

[norton_I]

If it isn't actually a security risk (I have no idea if it is or not), the most secure thing to do is to not "fix" it. Changing code always carries the risk of introducing security problems.

The OpenBSD guys are pretty defensive about security. If they say it is not a problem, I am inclined to believe them.

Strike 2, OpenBSD.

[Neillparatzo]

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:Strike 2, OpenBSD.

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

What happened? Nothing happened. The OpenBSD team members are performing their task perfectly. They are computer security experts who have considered this problem, and found it to not be the issue that some others think it is. So they're doing the responsible thing, and not making willy-nilly changes to their codebase for the sake of a "security glitch" that really doesn't exist.

Re:Strike 2, OpenBSD.

[Anonymous Coward]

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.

Re:Uh what ... yeah

[Richard_at_work]

Webkit is LGPL, Apache is under the Apache license, Samba is under the GPL and CUPS (sourcecode copyright, company name and other tangibles) was purchased by Apple a year ago this month (as well as hiring the main developer).

Out of the four items you mention, only one is GPL. You could have done much better to suggest such examples as GCC et al.

The great thing about the BSD license, is that when people do contribute back (and they do, even big companies like Apple), you know its because they *want* to, not because they *have* to.

Re:What??

[Jugalator]

The flaw in the PRNG is not exploitable. Not unless you are root on the local machine and have the ability to stop all other processes. Wait.. what?

This could potentially provide a platform for attacks involving prediction of IP sequences and thus TCP data injection attacks.

Where is a local machine access required for that? It could provide attacks on the network traffic itself, by merely knowing which operating systems are involved in it.

Re:Uh what ... yeah

[Goaway]

Being given something is not a freedom. It may be a good thing, but stretching the definition of "freedom" to include that renders term almost entirely meaningless.

Don't conflate "things you want" with "freedom", please.

Theo is slow to change, but he will.

[argent]

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.

Code excerpt for the curious...

[davidbrit2]

http://xkcd.com/221/ Oh hush, you knew somebody would post it.

Software freedom is better when its inalienable.

[jbn-o]

So, in other words, the grandparent poster's point is valid and the larger more important issue remains: proprietary derivatives of non-copylefted free software uses the free software community as a market instead of treating us as equals.

The great thing about the BSD license, is that when people do contribute back (and they do, even big companies like Apple), you know its because they *want* to, not because they *have* to.

Nobody "has" to under the GPL; to the degree that what you said is true, the same is true of the GPL. Statements like yours ignore all the choices that lead up to distributing source code. There's nothing in the GPL that compels conveyance. There are only conditions in the GPL that compel source code conveyance with object code conveyance. It's trivially easy to not improve GPL-covered software or not distribute the improved version. The larger issue here is whether the free software community owes Apple anything. We don't. If they want to join us and work with us, great, if not they can write their own software. The GPL helps ensure that when people and organizations convey copies of programs they do so as equals. NeXT (now owned by Apple) already tried distributing GCC derivative software without distributing complete corresponding source code when GCC was under GPLv2. It made NeXT look like an ass and put them at risk of being able to distribute GCC at all. NeXT later rectified the situation by distributing complete corresponding source code in compliance with GPLv2.

Re:How many people actually use PRNG?

[Adam Hazzlebank]

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 amplify noise, pick up random radio interference or use Quantum random sources. In any case they should all have drivers to check the "randomness" of source. The only way they could be considered pseudo-random if, against the trend of modern physics, you believe that "randomness" does not exist and the universe is inherently deterministic.