Slashdot Log In
OpenBSD Will Not Fix PRNG Weakness
Posted by
kdawson
on Sun Feb 10, 2008 07:58 AM
from the random-acts-of-kndness dept.
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."
Related Stories
Submission: serious weakness in OpenBSD PRNG will not be fixed by Anonymous Coward
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
then exploit it (if you can) (Score:5, Insightful)
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) (Score:5, Informative)
Parent
Re:then exploit it (if you can) (Score:5, Informative)
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.
Parent
Re: (Score:2)
Re:then exploit it (if you can) (Score:4, Informative)
Quantum mechanics delivers true randomness, at least according to the standard interpretation.
Parent
Re: (Score:3, Interesting)
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
Re: (Score:3, Informative)
Re:then exploit it (if you can) (Score:5, Funny)
Parent
Re: (Score:3, Informative)
Because it is not part of the standard PC architecture ?
Re:then exploit it (if you can) (Score:5, Informative)
Parent
Re: (Score:3, Insightful)
True, but if you roll one yourself, the P in PRNG no longer has a second meaning of 'predictable.'
It does if you don't do it right, and you're unlikely to do it right unless you're a cryptographic expert. Just because your algorithm isn't published doesn't mean a competent codebreaker won't be able to crack it: ahref=http://en.wikipedia.org/wiki/Security_through_obscurityrel=url2html-8229 [slashdot.org]http://en.wikipedia.org/wiki/Security_through_obscurity>.
Uh what (Score:4, Insightful)
Re: Uh what (Score:5, Informative)
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.
Parent
Re: Uh what (Score:5, Informative)
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.
Parent
They'd more likely be used to compromise the user (Score:3, Insightful)
Not everything is about compromising someone's computer.
Re:Uh what (Score:5, Interesting)
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.
Parent
Re:Uh what (Score:5, Funny)
Parent
Re:Uh what (Score:5, Funny)
That's because he's so l33t he can pick a Slashdot id at random every time he posts.
Parent
Re: (Score:3, Informative)
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
Re: (Score:2, Interesting)
If BSD used the GPL, then Apple still wouldn't be providing a fix, because they wouldn't be using OSS at all. Neither licence is better than the other in this regard.
I don't agree with the trolling from either camp. The licence you release your code under is a matter of personal choice.
Re: (Score:3, Interesting)
While I would agree with you on the matter of trolling it really gets old when BSD users trumpet it constantly where-as in my experience GPL supporters tend to realise there are limitations. Of course I'm sure it is seen the same way across the bridge.
Re: (Score:3, Interesting)
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* t
Software freedom is better when its inalienable. (Score:4, Interesting)
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.
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.
Parent
Re: (Score:3, Informative)
Oh, and captain hater, last time I checked, the fix would be shared [apple.com].
Re: (Score:3, Insightful)
Re: (Score:2)
http://www.opensource.org/licenses/bsd-license.php [opensource.org]
Re: (Score:2, Insightful)
Apple are free to release their putative fix to the community, or not - their free choice. That's one more freedom, relative to being obliged to release any changes they make which lead to a binary release outisde of Apple, which the GPL would oblige.
There are plenty of folk who see that as a feature not a flaw.
Re: (Score:2)
Re:Uh what ... yeah (Score:4, Insightful)
Don't conflate "things you want" with "freedom", please.
Parent
Re: (Score:3, Insightful)
GPL has the same flaw, ya know. (Score:3, Insightful)
( * which only says something about making the code, and thus the fix, available if the code, or compiled version thereof, is distributed. )
The difference is trivial, isn't it. In both cases an existing fix would not automatically be contributed back.
Why this is so bad: DNS cache poisoning (Score:2, Informative)
OpenBSD secure?! (Score:4, Interesting)
Oh for Bob's sake! (Score:2, Insightful)
But when the PRNG for a non-MS operating system is shown to have a similar (but not identical) problem, it's "irrelevant"?
Strike 2, OpenBSD. (Score:5, Insightful)
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:3, Insightful)
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
Re:Strike 2, OpenBSD. (Score:5, Insightful)
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.
Parent
Theo is slow to change, but he will. (Score:5, Interesting)
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.
Parent
Re: (Score:3, Interesting)
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)
They're doctrinaire, sure (Score:3, Interesting)
Code excerpt for the curious... (Score:5, Funny)
Why doesn't software trust /dev/[u]random ? (Score:3, Informative)
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.
-Matt
Re:So much for high security (Score:5, Insightful)
The OpenBSD guys are pretty defensive about security. If they say it is not a problem, I am inclined to believe them.
Parent
Re: (Score:3, Insightful)
Re:If the OpenBSD devs say it isn't a security fla (Score:2, Insightful)
I see you don't remember how OpenBSD developers downplayed remote root vulnerability in mbuf code, until COREsecurity gived them working exploit
And this is that mega randomness with what OpenBSD team was so proud
Re:What?? (Score:5, Informative)
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.
Parent
Re: (Score:3, Insightful)
If flawed, predictable PRNG code is so 'irrelevant in the real world' why does even Microsoft seek to improve upon it?
"Strengthens the cryptography platform with a redesigned random number generator, which leverages the Trusted Platform Module (TPM), when present, for entropy and complies with the latest standards. The redesigned RNG uses the AES-based pseudo-random number generator (PRNG) from NIST Special Publication 800-90 by default. The Dual Elliptical Curve (Dual EC) PRNG from SP 800-90 is also availa
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
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 generators are not considered pseudo-random. As I understand it they usually ampli