Slashdot Mirror
Linux Servers' Entropy Pool Too Shallow, Compromising Security
The BBC reports that Black Hat presenters Bruce Potter and Sasha Woods described at this year's Black Hat Briefings a security flaw in Linux servers: too few events are feeding the entropy pool from which random numbers are drawn, which leaves the systems "more susceptible to well-known attacks." Unfortunately, [Potter] said, the entropy of the data streams on Linux servers was often very low because the machines were not generating enough raw information for them.
Also, he said, server security software did little to check whether a data stream had high or low entropy.
These pools often ran dry leaving encryption systems struggling to get good seeds for their random number generators, said Mr Potter. This might meant they were easier to guess and more susceptible to a brute force attack because seeds for new numbers were generated far less regularly than was recommended. Update: 08/10 01:05 GMT by T : Please note that Sasha Woods' name was mis-reported as Sasha Moore; that's now been changed in the text above.
So a random number walks into a bar. The barman says, "I was expecting you"
Server rooms could have cameras filming cats to generate more entropy from.
That's why i use
http://www.issihosts.com/haveg...
Wouldn't it be also beneficial to enlarge the pool size from the current 1024?
I wrote a software that used billions of random numbers drawn from /dev/urandom. Not only were they all unique when used as hashes of reasonable specific width in memory, but also when stored for permanent storage in databases over an extended period. Sure, that's not a good idea, but at the time the only solution we had. I think /dev/urandom is pretty good.
Time to go pro.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
When the pool runs out, it has to GENERATE a new psuedorandom number. It doesn't "weaken" the randomness. And they call themselves security researchers...if this is what graces BlackHat these days...it's not worth the time of day as it's not even to 2600 standards.
have something useful to contribute. And not mess up whole eco-systems. ;-)
How much of this problem is due to old assumptions about running on real hardware? That is to say the entropy pool is fed from lots of sources most of them system devices. Is this just an unintended consequence of running on cut down virtual hardware platforms?
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
This problem has been around forever, use a better software implementation or just use a hardware PRNG to generate more entropy like everyone else.
But it is running windows XP
For the interested: Understanding-And-Managing-Entropy-Usage Whitepaper Black Hat whitepaper.
So it seems this is the classic problem that (Linux) programmers are told to use /dev/urandom (which never blocks) and some programs are doing so at system startup thus there's the opportunity for there to be "insufficient" randomness because not enough entropy has been gathered at that point in time. In short: using /dev/urandom is OK but if you are using it for security purposes you should only do it after /dev/random would have stopped blocking for a given amount of data for the first time since system startup (but there's no easy way to determine this on Linux). Or is there? Since the v3.17 kernel there is the getrandom syscall which has the beahviour that if /dev/urandom has never been "initialised" it will block (or can be made to fail right away by using flags). More about the introduction of the Linux getrandom syscall can be read on the always good LWN. And yes the BSD's had defences against this type situation first :-)
So this is bad for Linux systems that make security related "things" that depend on randomness early in startup but there may be mild mitigations in real life. If the security material is regenerated at a later point after boot there may be enough entropy around. If the the system is rebooted but preserves entropy from the last boot this may be mitigated for random material generated in subsequent boots (so long as the material was generated after the randomness was reseeded). If entropy preservation never takes place then regeneration won't help early boot programs. If the material based on the randomness is never regenerated then again this doesn't help. If you take a VM image and the entropy seed isn't reset then you've stymied yourself as the system believe it has entropy that it really doesn't.
Virtualization is a strong candidate because everything can be so samey but it can happen on real hardware too - imagine a trying to generate randomness on a basic MIPS based home router with flash based disks, no hardware RNG, typically booting from a fixed extract RAM disk install and doesn't have hardware clock to save time when powered off but makes ssh certs early during its first boot...
This article, Myths about urandom, explains why it's generally silly to worry about dried-up entropy pools. There are two scenarios where this might be an issue:
1. There is a compromise that allows an attacker to calculate the internal state of the PRNG. /dev/urandom or /dev/random; you are hosed anyway.
1a. That could be because the PRNG is leaking information about its internal state through its output. That would be really bad, but there are no known or suspected attacks.
1b. The server is compromised in some other way. Then it wouldn't matter whether it's
2. There is no 'true' entropy at all, which could happen on a server which does not store its internal state between reboots and which does not manage to gather 512 bits of true entropy-generating interactions between boot time and the first use of /dev/urandom. This would be an issue only in very specific use cases, certainly not as generic as TFA suggests.
Avantslash: low-bandwidth mobile slashdot.
I admit to running a server that does not do much in the way of actual work. It would be nice if entropy was offered as a service by the hosting provider.
But I have a solution! A good solution! A GREAT solution! Behold! Yes, a banana! As we all know, bananas are radioactive! So all we need to do is attach a particle detector to our computer and put a bunch of bananas right on top! Boom! Bananarand! You'll just need to remember to change your bananas out every so often as their half-life is very short. After about a week your bananas will decay into fruit fly particles (I'm not a nuclear scientist, I just play one on TV.)
All right fine, if you don't want to use a banana, United Nuclear has some lovely uranium samples for sale at the moment. Pretty sure you get on a list if you actually order one. Possibly if you click on that link. The radioactive Fiestaware they're selling would probably also work. While you're there, check out their selection of EXTREMELY DANGEROUS MAGNETS!
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
This is very true now that everything goes towards virtualization and clouds. Systems in the cloud are especially susceptible to low entropy issues.
Companies like Amazon and Google should step up and provide true hardware entropy sources for systems that they host.
And it's a known problem because there was chatter about it for years yet no-one stepped up.
Hopefully exposure at Black Hat will finally get them to do something about it.
This isn't so much about entropy "drying up" a few days after the system has booted - this is more about generating random numbers just after a system has booted and before "enough" entropy was gathered in the first place. From your link:
Not everything is perfect /dev/urandom happily gives you not-so-random numbers before the kernel even had the chance to gather entropy. When is that? At system start, booting the computer.
[...]
Linux's
but also from your link
FreeBSD does the right thing[...]. At startup /dev/random blocks once until enough starting entropy has been gathered. Then it won't block ever again.
[...]
On Linux it isn't too bad, because Linux distributions save some random numbers when booting up the system (but after they have gathered some entropy, since the startup script doesn't run immediately after switching on the machine) into a seed file that is read next time the machine is booting.
[...]
And it doesn't help you the very first time a machine is running, but the Linux distributions usually do the same saving into a seed file when running the installer. So that's mostly okay.
[...]
Virtual machines are the other problem. Because people like to clone them, or rewind them to a previously saved check point, this seed file doesn't help you.
So not great but not (always) a disaster and modern Linux allows programs to counter this if they wish by using getrandom.
I attended the (very interesting) Black Hat talk, and neither the article nor the /. summary do a very good job of summarizing it.
From memory (I didn't take notes), the key points were:
1. Tracking the entropy pool is a little harder than you might expect, because the kernel itself uses quite a lot. The primary reason is ASLR, but there other ways the kernel uses entropy itself. The kernel is effectively drawing from /dev/urandom at a very high rate, pulling thousands of bits every time it starts a process.
2. /dev/urandom vs /dev/random work a little differently than most people expect. There are actually three entropy pools, a "main" pool, a /dev/random pool and a /dev/urandom pool. Both /dev/random and /dev/urandom use the same PRNG, and both try to maintain 0 bits of entropy in their local pools, drawing a block from the main pool when needed and mixing it into their local pools (keep in mind that a pool is many bytes of data plus an estimate of how much entropy is in that data). /dev/random, obviously, blocks when it runs out of entropy in its local pool and there isn't enough in the main pool to satisfy the request. /dev/urandom works the same way, except that (a) it won't block and (b) it won't draw the main pool below 128 bits. When the main pool drops to 128 bits, /dev/urandom stops pulling from it.
3. The rate of entropy going into the main pool is low, on the order of single-digit bits per second. For some reason Potter and Moore didn't understand, using a daemon to get bits from the CPU HWRNG not only didn't increase the estimated entropy inflow rate, but actually decreased it (I had to step out for a bit around that point in the talk so I missed details).
4. Points 1, 2, and 3 taken together mean that the entropy pool is basically never above 128 bits. The kernel is always drawing on /dev/urandom, typically at a much higher rate (hundreds to thousands of bits per second pulled from urandom vs <10 bits per second going in).
5. OpenSSL seeds its internal CPRNG during startup and then just uses it, potentially forever, without ever reseeding. Worse, when it seeds from /dev/urandom at startup it makes no effort to check whether or not the kernel pool has any entropy to give it. It just gets some bytes and goes. This means that if an apache server starts up when there isn't much entropy in the pool, that very small amount of entropy could get stretched over a very large number of cryptographic operations. (Aside: I do a little work on and with BoringSSL, Google's OpenSSL fork, and it does reseed regularly, and also uses a more trustworthy CPRNG. I highly recommend using BoringSSL rather than OpenSSL.)
6. Android actually does better than desktop/server Linux, producing many more bits per second of entropy, though still far less than are demanded. Potter attributes this to the rich source of randomness available from the cellular radios.
How much any of this matters is hard to say. Entropy estimation is something of a black art at best, or wild ass guess at worst. Also, the kernel is known to be extremely conservative with at least one of its entropy sources: the HW RNG in most CPUs. Because there's concern the NSA may have backdoored those HW RNGs the kernel assumes their output is perfectly predictable, meaning that it provides zero entropy. The kernel mixes in HW bits anyway, because they can't hurt even if they are 100% predictable, and to whatever extent they're unpredictable they help.
In addition, the whole concept of entropy pools of known size which are drawn down and refilled is an extremely conservative one. Modern CPRNGs are able to produce enormous amounts of uniformly-distributed, unpredictable bits from fairly small seeds -- say, 256 bits of entropy. Assuming the kernel ever manages to get even a
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I don't know how it's related to this article except the word "entropy", but that was a great read, thanks.
Adding entropy generation hardware on a motherboard or even in the CPU would be trivial.
Would it be cryptographically sound ? Probably not, but it's a hell of a lot better than the ad hoc system now in place.
Is there some sort of patent issue preventing this from happening or something ?
Absolute statements are never true
Servers process enormous amounts of data that could increase the entropy pool. Although they can be manipulated to some extent, the timing and content of network packets that reach them can hardly be predicted.
Religion is what happens when nature strikes and groupthink goes wrong.
Why don't they just use the RNG built into systemd??
Just cruising through this digital world at 33 1/3 rpm...
http://www.via.com.tw/en/initi...
apt-get install haveged
I do this for living. This presentation is FUD and not applicable for 99% of all configurations. Sure, some headless system with a solid state drive will encounter 'at rest' issues if they idle long enough. This why /dev/random design blocks. For that 1% cases you can always mix Intel RdRand, or Freescale SEC sources.
/dev/urandom, then all bets are off, as you need to guarantee that system always has sufficient entropy.
The real issue with Entropy is that developers keep using
What about an high speed ADC sampling white noise?
OpenBSD did some work on this a while ago. As usual they're ahead of things: http://undeadly.org/cgi?action=article&sid=20131230165736
I seriously can't believe modern hardware does not have hardware RNGs
Why not put a positive spin on it:
"Linux servers mostly process low entropy data - Stuff That Matters!"
There is one in some x86 CPUs, see there : https://en.wikipedia.org/wiki/...
Server CPUs most definitely have it. But you need _trusted_ hardware random number generators. And so far it all falls flat on the "trusted" part, at least for the CPU-included ones.
So what ever happened to "save the random state at shutdown, and restore the random state at startup"? That, I thought, was standard behavior as of about a decade ago.
If that wasn't enough, then every so often (no more than once a day or so), grab 1K of random bytes from random.org, and add it to the pool at a slow and steady rate (when /dev/random would block, for example); refill that buffer when empty if enough time has passed.
Yes, that basically means 1K bytes, or 8K bits, of entropy only for /dev/random, that would not be visible to /dev/urandom. People using urandom are basically saying that they don't need the really good numbers, right?
Imagine a hypervisor spinning up 120 identical Linux instances - they all generate ssh-keys at the same time during boot/install (+- ms'). How can that be "good"? It will probably survive statistical testing but so a LCG. I have serious doubt that there is enough entropy in ze clouds. Btw: coolest way to harvest entropy is to feed your PRNG with SDR-input.