OpenBSD Will Not Fix PRNG Weakness 196
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."
Why this is so bad: DNS cache poisoning (Score:2, Informative)
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.
Re:then exploit it (if you can) (Score:5, Informative)
XYZ Attacks were also unthinkable a while ago. (Score:2, Informative)
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 in fixing this topic, or just review the *BSD solution and paste it into the OpenBSD sourcetree with their background, I can only say this behaviour is untrustworthy.
Re: Uh what (Score:2, Informative)
Re:then exploit it (if you can) (Score:4, Informative)
Quantum mechanics delivers true randomness, at least according to the standard interpretation.
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.
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.
Re:then exploit it (if you can) (Score:5, Informative)
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.
Re:Uh what ... yeah (Score:3, Informative)
Oh, and captain hater, last time I checked, the fix would be shared [apple.com].
Re:So much for high security (Score:2, Informative)
OpenBSD's argument is that a patch would not make it more secure... so your point is moot.
Re:Uh what ... yeah (Score:2, Informative)
Re:then exploit it (if you can) (Score:1, Informative)
This is all a bunch of nonsense. You can't poison DNS caches without either a) compromising an upstream DNS server or b) compromising an upstream router. *Perhaps* you could DoS the upstream router, take over its IP, become the router yourself (assuming you have some other route to the outside), hope nobody served by that router notices that half the internet is dead, and then masquerade as the upstream DNS server. Then of course if you want to really do damage you'll need to forge SSL keys. But none of this requires cracking the PRNG.
Name servers are not a system for trust. Cryptography is.
Re:then exploit it (if you can) (Score:2, Informative)
I would have thought all algorithmic solutions to random number generation would suffer the same flaw as described in the text. Be in deep shit if it worked any other way.
Re:then exploit it (if you can) (Score:1, Informative)
I looked around the page you linked to looking to see what malicious things this bug allows, and all I saw was a whole lot of "potentially this, possibly that" scenarios. Well, yeah, and it says on my medicine here that taking one pill might possibly cause side effects like sudden death. The point is that unless there's actual evidence that this bug can be used maliciously, why get so worried about "potential" exploits?
Re:Uh what (Score:2, Informative)
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 on those platforms and the results achieved, he is occasionally interesting but is much less often right than in those other areas. Unfortunately, he tends to exaggerate his area of expertise and the basis on which he was awarded his doctorate in arguments from authority.
Since most of this is readily found via your favourite Internet search engine, including the search box at the top of every slashdot page, you can easily check your own initial addition.
Re:How many people actually use PRNG? (Score:3, Informative)
Re:Uh what (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 CTO but I do report to the CTO. Nor am I aware of any occasion where I have ever discussed the results of deep inelastic scattering experiments at ZEUS on Slashdot or any other forum.
Re:What?? (Score:1, Informative)
http://undeadly.org/cgi?action=article&sid=20070725193920 [undeadly.org]
Jakob Schlyter (jakob@) wrote to misc@:
as some of you may have noticed, a new weakness in BIND 9 has
recently been discovered. using this weakness, an attacker can
remotely poison the cache of any BIND 9 server. the attacker can do
this due to a weakness in the transaction ID generation algorithm used.
when BIND 9 was first imported into OpenBSD, we decided not to use
the default ID generation algorithm (LFSR, Linear Feedback Shift
Register) but to use a more proven algorithm (LCG, Linear
Congruential Generator) instead. thanks to this wise decision, the
BIND 9 shipped with OpenBSD does not have this weakness.
the proactive security of OpenBSD strikes again,
jakob
ref: http://www.trusteer.com/docs/bind9dns.html [trusteer.com]
Re:then exploit it (if you can) (Score:3, Informative)
Re:Strike 2, OpenBSD. (Score:1, Informative)
http://www.nabble.com/prng-and-a-fix-wich-should-(not-)-happen..--to15399833.html [nabble.com]
Re:then exploit it (if you can) (Score:3, Informative)
Because it is not part of the standard PC architecture ?
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:Why doesn't software trust /dev/[u]random ? (Score:2, Informative)
To your question, why doesn't BIND9 have a build option to use the underlying OS PRNG (in /dev or libc or whatever), it's partly because this problem isn't solveable without DNSSEC so a better PRNG for 16-bit query-ID's is bad engineering economics, and partly because BIND9's PRNG is "good enough" for a 16-bit field and we (ISC) don't want the risk that some BIND builds will pull in really terrible OS PRNG's. Our BIND9 PRNG isn't cryptostrength... but spending more time on it won't make DNS more secure, only DNSSEC can do that. If DragonflyBSD wants to help secure the DNS, then make DNSSEC the default on all your systems, sign your own zones, and encourage your users to sign their zones. If your parent zone (.ORG, .COM, etc) won't take your DNSSEC keys, put them in DLV [isc.org]. DNSSEC is stuck in IPv6-like chicken-or-egg mode, and only dedicated coherent action from the F/L/OSS community has ever been able to unstick stuff like this.
But debates around the quality of a PRNG used to generate 16-bit integers are unproductive time thieves. We used to use the C "++" operator to select the next query ID, and in some ways I wish we had kept that practice rather than adding any kind of PRNG at all since it only gave the illusion of security without making query-ID guessing attacks impossible or even impractical.
Paul Vixie