Right, which means that there will be a disproportionate number of FreeBSD developers running it. These developers have commit access to the source tree, including -STABLE and -RELEASE.
Approximately the worst possible vulnerability, arguably worse than kernel RCE, because a kernel RCE requires an active attacker to intersect with the vulnerable host while it's still there; the broken RNG will leak secrets that will be usable retroactively.
Well, no. It was caught in the CURRENT branch -- i.e. latest-and-greatest snapshots for developers. Users who use this branch are supposed to accept some breakage here and there.
Security requires a threat model. Something can only be "the worst possible vulnerability" if it causes a large amount of damage consistent via the threats which are in the model. The threats that you're thinking of are not usually contained within the models of cutting-edge-dev-systems, which will be protected by firewalls etc. on intranets.
There's really a need in both cases for "an active attacker to intersect with the vulnerable host while it's still there." A broken RNG in such circumstances is much, much weaker than kernel RCE.
How bad is the randomness here? Totally predictable? Predictable if you don't have an external entropy source (e.g. a hardware RNG)? Predictable if you don't have user input (e.g. keyboard typing etc)?
I actually wonder how serious this is. I know that if the RNG wasn't seeded properly the random numbers will be somehow predictable. But what do you need to know exactly to predict them? The time of seeding? The time of the number generation? How would one obtain either for an SSH key, and use it to break it? I am genuinely curious.
Would a broken RNG be a risk to leak private keys? As in, even if the key was generated on a safe kernel, merely using the key to encrypt or sign data on the broken kernel would compromise the keys?
Not sure about the keys themselves if they've already been generated, but even after a key is generated, a lot of situational stuff involves random numbers (session keys, initialization vectors, nonces, etc), and lesser variation in these can make it easier to attack traffic with known content patterns.
Reading the comments here is somewhat frustrating. Even the most recent ones seem to miss the significance of the RNG bug being in the -CURRENT branch only.
They found a bug, and it will be fixed. The fact that this bug was found in -CURRENT is a good a thing. This is a pre-alpha, not for production release. The development model is working as intended, no?
I think the tide of blaming people running CURRENT and attempting to dismiss the issue instead of addressing the extremely serious vulnerability is troubling, since even in the limited Venn diagram of people I know that run FreeBSD, one of them matches this template:
1. STABLE prod fleet
2. CURRENT dev workstation
3. TLS certificate private keys in prod generated on CURRENT workstation to be signed by authority
4. Potentially vulnerable TLS keys existing in STABLE fleet
You folks can twist this to try to deflect severity by pointing to CURRENT, but in the real world, it existing at all for four months is extremely serious and must be taken seriously. My production TLS keys were created on my OS X laptop, because I don't often have to think about a compromised random number generator and this is a tradeoff I make in my own life.
I guess if I truly cared about my TLS keys, I should have made them on a copy of airgapped Warty Warthog and run them through a shitload of random analysis tools before shipping them off to be signed. My bad.
It is very good that the bug was found and fixed in -CURRENT, but it's also important not to be dismissive of the issue. It is unfortunate that some recent posters are clearly confusing -CURRENT with the stable branch from which releases are cut. However, this is a very serious flaw that existed in the tree for some time, and is indeed a big concern in the FreeBSD developer community.
As a bit of a tangent: Does this happen semi-regularly because proving "randomness" is so difficult? Is there a system which can, with enough data, show that something is at least nth degree of randomness or is such a thing impossible mathematically?
I would guess so, yes. You can never prove that something is random, merely that it behaves randomly "enough". There are lots of testsuites[1][2] you can run that will test that a generator is uniform and doesn't follow any patterns or has any other statistical weaknesses, but you can never prove that something is fully random without knowing the process that generates those numbers. A statistically sound RNG might just output the digits of pi, which would be non-repeating, uniform and pass any randomness test, but if you knew which digit the RNG started from and how many it has output so far you can easily predict the next one. Likewise if you're given a large enough sample you can search the digits to figure out the state of the RNG.
Statistical tests exist, but when it comes to cryptographic security, they are virtually useless. A statistical test attempts to examine a stream of bits and determine if they "look random" from a narrow, naive point of view, often predefined ahead of time.
On the other hand, a cryptographic adversary actively seeks to break the RNG, which may include tricks that statistical tests simply do not account for. As an example, the Mersenne Twister passes many statistical tests, but after observing 630 or so outputs, an intelligent adversary (with some math) can predict all future outputs of the RNG. That is not something a simple test can uncover.
So, essentially, if your RNG fails statistical tests, it is totally unworthy of any consideration at all from a cryptographic standpoint. If it passes all the selected statistical tests, good for it---all that means is that it might not be totally broken.
That isn't to say that statistical tests are without value. If they were in the build checking process, they could spot when the RNG has failed catastrophically, sometimes. They could not spot when cryptographic problems arise, though.
There are fairly standard statistical tests for randomness. They can't be 100% perfect (if it is truly random you can expect some results that don't look random occasionally) but with enough runs you can be sure to an acceptable degree.
It can't be beyond the wit of man to add such tests to automatic build and regression tests if the project has such a process in place, though it would potentially slow that process down depending on how you define the "acceptable degree" and therefore how aggressively you test.
Proving "randomness" is impossible, akin to finding the shortest program to reproduce a larger string (Kolmogorov complexity). Strings are Kolmogorov Random when they can not possibly be compressed any further by any program: Kolmogorov Random strings simply have no predictable information left to use for further compression. But Kolmogorov Complexity (KC) can not be computed, since that causes a paradox, much like "A description of the natural number that can not be described in less than fifty English words".
But we can of course talk about a degree of randomness, like we can also try to approach KC. Good randomness is all about unpredictability (given the first half of a random string, can you use that to predict the second half?), but that does not mean that proper randomness should be void of identifiable patterns (such as "00000000111111111" in a random binary string). Such orderly-looking patterns do appear in proper randomness, because the absence of those patterns would make the randomness more predictable, not less.
You can measure level of randomness with statistical methods [1], compression [2], visual methods [3] and die-hard tests [4]
[1] A simple method is the chi-square test.
[2] Compression ratio tells us something about the randomness. Random data can not be compressed by everyday-use compressors. That no one claimed the money for the challenge to compress RAND's digits in a binary file tells us something about the rigor that team had in coming up with random numbers. The more you can compress a string, the more order it contains and the more predictable it is.
[3] You can plot random points inside a circle. After a lot of points are added, you should see no patterns and a properly, evenly spaced circle. Another method are Moiré patterns: Take a field of random noise, copy it, slightly rotate it, and overlay. Non-random patterns will become more visible. But these patterns are visible without Moiré rotation too when using very basic PRNG's like the standard Python random library.
Coming from just the data, I'd say impossible. It would be like achieving infinite compression on any pseudorandom data. There's no practical way to search through all possible short algorithms that could generate it.
With knowledge of the algorithm, you can do a lot more.
I fail to see how a bug in a development branch that nobody should be using in production is worth discussing, from a security incident perspective. Perhaps ways of catching that category of bug in an automated way would be an interesting topic.
Probably, yes. Upthread, someone looked at the code and suggested that it fell back on a linear congruential generator as an RNG. If that is true, I'd expect the Dieharder tests to fail it.
Maybe FreeBSD would do well to rename their 'CURRENT' branch to something suggesting less that to be with the times you need that one. I'm aware of the difference between 'CURRENT' and 'STABLE' but I think that name is at a minimum suggestive enough that people might (and probably have) fall for it.
Something like 'DEVELOPMENT' or 'NOTFORPROD' instead of 'CURRENT'?
As far as facts go, there is no indication that whoever is using -CURRENT in production is doing so out of ignorance. I've only seen hearsay so far and I'm guessing that number is very small and comprises actually knowledgeable people that know the risks.
Additionally, it's stamped everywhere [1], if one cares to look, that CURRENT is unsupported, bleeding edge, buggy, "will not build sometimes", etc. Do we really want to modify a development process that has been in use for over a decade because of a few clueless/extremely-gifted people?
Another possibility is that this person is a FreeBSD jedi, well aware of the risks and payoffs. In that case, this bug is no surprise and she/he is prepared to act on it and regenerate some keys, review commit logs (if a developer), and look for signs of intrusion etc.
I still think this is a "non-news" and poor attempt to use HN to spread fear and trigger useless discussions. The usual drama show.
The linux kernel development branch is called "mainline" - people know that distributions take upstream changes and integrate into their distributed kernels, and not use use "mainline" kernels directly.
Do you want linux to change to "DEVELOPMENT" or "NOT FOR PROD" instead of "mainline"?
It's a matter of staying literate and actually reading what the docs say.
Libc arc4random still uses rc4. The kernel code is actually kind of tangly. I think it still uses rc4 for explicit arc4random calls, but I'm not certain exactly what comes out of /dev/random.
Yes, I'm very interested in this too. A bug like this could very well be an attack. It could also be an honest mistake, crypto is hard after all. I'm hoping someone will research this and provide a nice write-up.
It shouldn't affect end-to-end encryption, because those keys should only be generated at the endpoints (i.e. the users' devices, probably not running FreeBSD). It could affect TLS, etc, however.
[+] [-] emaste|11 years ago|reply
[+] [-] tptacek|11 years ago|reply
[+] [-] dlitz|11 years ago|reply
[+] [-] tptacek|11 years ago|reply
Ouch.
[+] [-] drostie|11 years ago|reply
Security requires a threat model. Something can only be "the worst possible vulnerability" if it causes a large amount of damage consistent via the threats which are in the model. The threats that you're thinking of are not usually contained within the models of cutting-edge-dev-systems, which will be protected by firewalls etc. on intranets.
There's really a need in both cases for "an active attacker to intersect with the vulnerable host while it's still there." A broken RNG in such circumstances is much, much weaker than kernel RCE.
[+] [-] richardwhiuk|11 years ago|reply
[+] [-] sarciszewski|11 years ago|reply
[+] [-] gambiting|11 years ago|reply
[+] [-] 0x0|11 years ago|reply
This article mentions DSA private keys and poor RNGs: http://rdist.root.org/2010/11/19/dsa-requirements-for-random...
[+] [-] atonse|11 years ago|reply
[+] [-] emaste|11 years ago|reply
[+] [-] tylersmith|11 years ago|reply
[+] [-] autoreleasepool|11 years ago|reply
They found a bug, and it will be fixed. The fact that this bug was found in -CURRENT is a good a thing. This is a pre-alpha, not for production release. The development model is working as intended, no?
[+] [-] jsmthrowaway|11 years ago|reply
1. STABLE prod fleet
2. CURRENT dev workstation
3. TLS certificate private keys in prod generated on CURRENT workstation to be signed by authority
4. Potentially vulnerable TLS keys existing in STABLE fleet
You folks can twist this to try to deflect severity by pointing to CURRENT, but in the real world, it existing at all for four months is extremely serious and must be taken seriously. My production TLS keys were created on my OS X laptop, because I don't often have to think about a compromised random number generator and this is a tradeoff I make in my own life.
I guess if I truly cared about my TLS keys, I should have made them on a copy of airgapped Warty Warthog and run them through a shitload of random analysis tools before shipping them off to be signed. My bad.
[+] [-] emaste|11 years ago|reply
[+] [-] peri|11 years ago|reply
[+] [-] Someone1234|11 years ago|reply
[+] [-] thusoy|11 years ago|reply
[1]: dieharder: http://www.phy.duke.edu/~rgb/General/dieharder.php
[2]: http://csrc.nist.gov/publications/nistpubs/800-22-rev1a/SP80...
[+] [-] ReidZB|11 years ago|reply
On the other hand, a cryptographic adversary actively seeks to break the RNG, which may include tricks that statistical tests simply do not account for. As an example, the Mersenne Twister passes many statistical tests, but after observing 630 or so outputs, an intelligent adversary (with some math) can predict all future outputs of the RNG. That is not something a simple test can uncover.
So, essentially, if your RNG fails statistical tests, it is totally unworthy of any consideration at all from a cryptographic standpoint. If it passes all the selected statistical tests, good for it---all that means is that it might not be totally broken.
That isn't to say that statistical tests are without value. If they were in the build checking process, they could spot when the RNG has failed catastrophically, sometimes. They could not spot when cryptographic problems arise, though.
[+] [-] dspillett|11 years ago|reply
It can't be beyond the wit of man to add such tests to automatic build and regression tests if the project has such a process in place, though it would potentially slow that process down depending on how you define the "acceptable degree" and therefore how aggressively you test.
[+] [-] compbio|11 years ago|reply
But we can of course talk about a degree of randomness, like we can also try to approach KC. Good randomness is all about unpredictability (given the first half of a random string, can you use that to predict the second half?), but that does not mean that proper randomness should be void of identifiable patterns (such as "00000000111111111" in a random binary string). Such orderly-looking patterns do appear in proper randomness, because the absence of those patterns would make the randomness more predictable, not less.
You can measure level of randomness with statistical methods [1], compression [2], visual methods [3] and die-hard tests [4]
[1] A simple method is the chi-square test.
[2] Compression ratio tells us something about the randomness. Random data can not be compressed by everyday-use compressors. That no one claimed the money for the challenge to compress RAND's digits in a binary file tells us something about the rigor that team had in coming up with random numbers. The more you can compress a string, the more order it contains and the more predictable it is.
[3] You can plot random points inside a circle. After a lot of points are added, you should see no patterns and a properly, evenly spaced circle. Another method are Moiré patterns: Take a field of random noise, copy it, slightly rotate it, and overlay. Non-random patterns will become more visible. But these patterns are visible without Moiré rotation too when using very basic PRNG's like the standard Python random library.
[4] The programmer's way of brute-forcing a lot of simulation runs to see if the PRNG works as expected: http://en.wikipedia.org/wiki/Diehard_tests
[+] [-] jackweirdy|11 years ago|reply
[+] [-] indrax|11 years ago|reply
With knowledge of the algorithm, you can do a lot more.
[+] [-] jahnu|11 years ago|reply
http://dilbert.com/strip/2001-10-25
[+] [-] dpkendal|11 years ago|reply
[+] [-] gtirloni|11 years ago|reply
[+] [-] comboy|11 years ago|reply
[+] [-] emaste|11 years ago|reply
[+] [-] peterwwillis|11 years ago|reply
[+] [-] ReidZB|11 years ago|reply
[+] [-] jacquesm|11 years ago|reply
Something like 'DEVELOPMENT' or 'NOTFORPROD' instead of 'CURRENT'?
[+] [-] gtirloni|11 years ago|reply
Additionally, it's stamped everywhere [1], if one cares to look, that CURRENT is unsupported, bleeding edge, buggy, "will not build sometimes", etc. Do we really want to modify a development process that has been in use for over a decade because of a few clueless/extremely-gifted people?
Another possibility is that this person is a FreeBSD jedi, well aware of the risks and payoffs. In that case, this bug is no surprise and she/he is prepared to act on it and regenerate some keys, review commit logs (if a developer), and look for signs of intrusion etc.
I still think this is a "non-news" and poor attempt to use HN to spread fear and trigger useless discussions. The usual drama show.
[1] https://www.google.com.br/search?q=freebsd+current
[+] [-] barkingcat|11 years ago|reply
Do you want linux to change to "DEVELOPMENT" or "NOT FOR PROD" instead of "mainline"?
It's a matter of staying literate and actually reading what the docs say.
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] citrin_ru|11 years ago|reply
"This does not effect programs that directly used /dev/random or /dev/urandom."
openssl should use /dev/random for key generation and keys generated by openssl is not affected?
[+] [-] anologwintermut|11 years ago|reply
[+] [-] tedunangst|11 years ago|reply
[+] [-] Animats|11 years ago|reply
Name?
[+] [-] tedunangst|11 years ago|reply
[+] [-] BetaCygni|11 years ago|reply
[+] [-] tete|11 years ago|reply
[+] [-] infruset|11 years ago|reply
[+] [-] ikeboy|11 years ago|reply
[+] [-] louwrentius|11 years ago|reply
[+] [-] aaronchall|11 years ago|reply
[+] [-] discardorama|11 years ago|reply
[+] [-] X-Istence|11 years ago|reply
[+] [-] tptacek|11 years ago|reply
[+] [-] timmclean|11 years ago|reply
[+] [-] evandena|11 years ago|reply