CPU-integrated hardware RNGs when?
Whoops! Tiny bug in NetBSD 6.0 code ruins SSH crypto keys
The brains behind NetBSD have warned a bug in the open-source OS creates weak cryptographic keys that can be cracked by attackers. Users attempting to secure sensitive communications, such as SSH terminal connections, using the dodgy keys could be easily snooped on and their data decrypted. The use of a cryptographically …
-
-
-
Tuesday 26th March 2013 10:25 GMT Destroy All Monsters
Also, when french-propelled cows fall from the sky they may land on your valet.
Seriously, the tests on these pieces of kit are pretty good and not at webmonkey level.
-
-
-
Tuesday 26th March 2013 12:04 GMT Destroy All Monsters
Re: Hardware RNG's are already here
Id didn't know about the VIA implementation. Since January 2003, too.
So what's keeping the others?
You can also buy pricey add-on cards, I see.
-
-
Tuesday 26th March 2013 13:02 GMT Ru
It is entirely possible to use a hardware RNG as a source of entropy and yet still completely balls up your key generation. Hardware support for encryption and decryption is not the same as hardware key generation, incidentally.
A cursory search turns up a netbsd bugreport from 2006 talking about a driver for an intel hardware RNG. It may be reasonably assumed that the project has hardware RNG support since that time, but I'm entirely too lazy to verify this. Certainly other BSDs and *nixes have supported such devices for some time.
-
Tuesday 26th March 2013 13:20 GMT Nigel 11
Don't virtually all PCs have a hardware RNG these days? Although it's rarely used as such. It's the integrated audio system.
Rack up the gain on the microphone input and you'll hear noise generated by the switching of other electronic systems in the box. (Even better if a mic is connected and you pick up external noises). It shouldn't be hard to generate a fairly random number from a second's worth of samples thereof. It may not be good enough for crypto on its own, but XORing it with a "good" random number cannot make it any less good.
-
This post has been deleted by its author
-
-
Tuesday 26th March 2013 23:07 GMT JassMan
@Larry F54
IMHO radiation generated random numbers are only suitable for a small batch produced in a relatively short time. OK many isotopes have an extremely long half life but they all have a half life. By definition this means that the output of the generator is "coloured" and therefore not truely random.
-
-
-
-
-
Tuesday 26th March 2013 09:58 GMT Anonymous Coward
Not the first time.
http://linuxhaters.blogspot.com/2008/05/gcc-opensslc-fno-random-seed.html
"You see, opening your source code leads to more eyes looking at your code. Yes. But leaving the distribution tasks to, well, distributions, means there are also more hands (and guys, admit it, more dicks) to fuck your code up. I gotta give it to this Slashdot commenter who correctly stated: this is SSL with muppet extensions."
http://it.slashdot.org/story/08/05/13/1533212/debian-bug-leaves-private-sslssh-keys-guessable
-
Tuesday 26th March 2013 10:15 GMT Anonymous Coward
Re: Not the first time.
The OpenSSL bug in Debian was an interesting one. The package maintainer "fixed" the code based on the output of a static analysis tool that warned about a dodgy looking bit of code. The code was doing something that ordinarily is a no-no, but in this case it was being done deliberately. Unfortunately, the original author of the code hadn't seen fit to put in a comment stating why this was being done. So I'd argue it was ultimately a failure of the original author of the code, as dong tricksy shit like he or she did is only ever permissible if it's well documented.
-
Tuesday 26th March 2013 10:51 GMT Anonymous Dutch Coward
Re: Document your tricksy shit?
Well yes and no.
If you're messing with crypto code you'd better know what you're doing in the first place. Removing something because a static code generator says so says more about the guy removing it than the quality of the comments.
That said, commenting never hurts and yes, it will perhaps prevent the same mistake.
-
Tuesday 26th March 2013 12:38 GMT Philip Hands
Re: Document your tricksy shit?
Also, Kurt (the maintainer in quesion) did ask about whether it was a good idea to "fix" said tricksy shit, on the openssl-devel mailing list, and recieved only positive noises in response.
It was later revealed that the OpenSSL developers generally don't read their -devel list, because it's too noisy, and instead hang out elsewhere -- feel free to make your own judgements about the overall wisdom of that, and how to allocate the blame arising from the Debian patch.
-
Tuesday 26th March 2013 12:50 GMT Anonymous Coward
Re: Document your tricksy shit?
If you're messing with crypto code you'd better know what you're doing in the first place.
It didn't really reflect on the maintainers knowledge of crypto coding - the original author of the code was doing something frankly stupid that relies on an assumption that uninitialised data will provide additional entropy. Nothing in the C standard precludes an implementation scrubbing freed memory, and I've worked on a platform that does exactly that by zeroing it out.
-
This post has been deleted by its author
-
This post has been deleted by its author
-
-
Tuesday 26th March 2013 19:44 GMT jake
Seen in a five page bit of in-line assembly language, kernel code, K&R C, circa 1985
* I don't remember exactly why I wrote this shim, nor what it does
* It was late, I had several beers ... you've been there, admit it
* But don't change it or everything else breaks!
It's been in my personal `fortune` file since I first ran across it :-)
-
-
-
-
-
-
-
This post has been deleted by its author
-
-
-
Tuesday 26th March 2013 10:18 GMT Chavdar Ivanov
So what?
I have been running NetBSD since the halcyon days of 1.5... There is hardly a better bunch of OS developers out there, usually responding within the hour on one of the lists. My impression is that anyone who uses NetBSD in production keeps an eye on the discussions, especially security advisories. Patching is trivial. I very much doubt there was even an attempt to use this, let alone to succeed. One could argue that OEMs using NetBSD as a platform would suffer more in providing the firmware updates to their systems, but I'd suggest that these still use mostly NetBSD 5 and earlier, so it is unlikely many have been affected.
This is not the first security advisory related to NetBSD, but probably the first to attract such an attention. Move over.
And yes, I run -current only, it has been extremely stable for me for a code in constant development (it fluctuates, of course, one has to be careful with the 'sysupgrade auto' bit and do it after certain testing).
-
Tuesday 26th March 2013 12:09 GMT John Smith 19
Every f**king time its the random number generator.
This IIRC is not the first time some network protocol relied on a number being "random" and it turned out it was not.
My instinct is despite it being an active research topic since the 1950s implementing the research is demanding and easily FUBAR'd.
Let me suggest that a)If you're implementing one and you do some tricky possibly non portable, possibly inefficient (but essential to algorithm correctness) thing you document it.
In the space shuttle flight software code they called these "alibis." If it's good enough for maintaining life threatening computer code it's good enough for you.
If you're reading it don't change it unless you really understand what's going on.
-
Tuesday 26th March 2013 14:44 GMT Benchops
Not just your key
If this is anything like the Debian -> Ubuntu key problem a few years back then it's not just your ssh key you need to change. You NEED to make sure that you trawl round all accounts where you put your public key in the authorized_key[2] file as /that/ is where the attackers will get in with a predictable key.
-
Tuesday 26th March 2013 20:33 GMT Anonymous Coward
Re: Not just your key
The bug only affects things very soon after boot. This is a problem for any autogenerated keys on boot (e.g. ssh host keys) before much entropy has been gathered-- the system should have waited until enough entropy was available to generate the keys, but instead it waited only until 32 bits of entropy were available. Your ssh user keys are probably ok if you did anything interactive before using them-- interaction provides entropy.
-
-
-
Wednesday 27th March 2013 17:40 GMT asdf
Re: wow dodged a bullet
>Better check your routers, set top boxes and other devices with similar capabilities.
Router - Linux based Gargoyle firmware (pretty solid too), would like to run OpenBSD but too much of a pain to setup (if even possible) on the standard gaming commodity router I own.
Directv setup top box might be running it though for all I know. That might explain why its so laggy. Pretty much everything else with internet access in my house is certainly not running NetBSD.
-
-
-
Saturday 30th March 2013 15:56 GMT Chavdar Ivanov
Further development... the fix that wasn't.
Apparently it turned out the fix was incorrect... Subsequent analysis is even more entertaining, see
http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2013-003.txt.asc
(especially the tls@ credit - "... for causing, finding, "fixing", and fixing the bug
and helping with this advisory.").