Feeds

back to article 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 flawed …

COMMENTS

This topic is closed for new posts.
Silver badge
Flame

CPU-integrated hardware RNGs when?

0
1
Anonymous Coward

And if/when they discover a similar weakness in a CPU-integrated hardware RNG it will affect every OS using the CPU.

4
1
Silver badge
Flame

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.

Behind Intel's New Random-Number Generator

3
0
Thumb Up

Hardware RNG's are already here

My VIA eden based home webserver (ok its actually a recycled thin client) has this feature allready as well as hardware accelerated AES and RSA. See cpuflags: rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en

3
0
Silver badge
Pint

The trivial thought came to me while on the karzy that, if additional trust is needed, one can just XOR the bits from the hardware RNG and the software RNG. Then both have to be foobared pretty seriously to give a compressible result.

0
0
Silver badge
Holmes

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.

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

3
0
Silver badge
Alert

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.

1
0
Bronze badge
Happy

Computers should come with a built-in radiation source and Geiger counter RNG.

0
0
Silver badge
Thumb Down

You don't need anything radioactive! A noise diode is quite good enough.

1
0
h3
Bronze badge

What a useless article - doesn't say whether it affects 6.1-RC? or 6.0.1

0
0
Coat

a built-in radiation source and Geiger counter RNG

I tried that once, but then /bin/cat would die about half the time.

12
0
Silver badge

@Blain (was:Re: a built-in radiation source and Geiger counter RNG)

/dev/whippet thinks that putting t'cat in t'bin is a good idea.

0
0
Trollface

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

0
1
RW
Boffin

You win the prize. All other so-called random number generators are only pseudo-RNGs.

This is a well-known fact that is unfortunately not as well known as it should be.

0
0
Bronze badge
Happy

At least...

1) We are told about it

2) There is a patch.

Unlike another company(s) i could mention, that wouldnt tell you and release a patch 6 months from now once a load of machines are compromised.

8
1
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

3
2
Bronze badge

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.

9
1
Bronze badge
WTF?

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.

9
0

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.

7
0
Bronze badge

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.

5
0
Joke

Re: Document your tricksy shit?

"That said, commenting never hurts and yes, it will perhaps prevent the same mistake."

As some wise person once said, "Real programmers don't comment their code. It was hard to write, it should be hard to understand."

;)

1
0
Silver badge

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 :-)

1
0
Anonymous Coward

Re: Document your tricksy shit? - Chris Wareham

You've worked on MULTICS?

0
0

This post has been deleted by its author

This post has been deleted by its author

Go

RNG quotation

"Random numbers should not be generated with a

method chosen at random." Donald Knuth

Source: https://www.random.org/quotations/

4
0
Silver badge

Re: RNG quotation

http://xkcd.com/221/

3
2
Bronze badge
WTF?

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

3
0
Bronze badge

Re: So what?

I've been running NetBSD since 1.3, and it certainly is a great platform both code and community wise. 1.5 was definitely a sweet spot for me as well, although the release with the second threading implementation was an impressive one with regard to performance gains.

0
0
Gold badge
Flame

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.

0
0
Boffin

Raspberry Pi

Apparently the CPU used in the PI has a hardware RNG. Back in February they added kernel support for it:

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=29&t=19334&p=277747#p277747

it sounds like it uses a thermal entropy source.

3
1
Bronze badge

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.

0
0
Bronze badge

Re: Not just your key

Debian supplied blacklist packages so that known insecure keys couldn't be use to autheticate.. other distros/system admins could have implemented those blacklists too if insecure debian keys was a major problem for them.

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

0
0
Bronze badge
Unhappy

Brilliant

"Random numbers to important to be left to chance"

Dear Sir, you owe me a keyboard.

1
0
Bronze badge

Just remember...

Some state lotteries here in the USA use computerized "random" numbers to generate the draws.

So, "Random numbers for fun" takes on a whole new meaning!

0
0
Silver badge
Trollface

wow dodged a bullet

Glad this happened to NetBSD and not to one of the important BSD's people actually use like DragonFly BSD, FreeBSD or OpenBSD.

0
2
Anonymous Coward

Re: wow dodged a bullet

Better check your routers, set top boxes and other devices with similar capabilities. A lot of them run NetBSD, including things such as wireless access points from a certain fruity firm (I know one of the NetBSD contributors who was contracted to work on them).

0
0
Silver badge
Trollface

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.

0
0
Bronze badge
Devil

NetBSD - it runs on anything...

The "NetBSD Toaster" takes on a whole new meaning...

0
0
Thumb Up

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

0
0
This topic is closed for new posts.