Can we please stop cargo-culting the "fact" that /dev/random outputs raw entropy while /dev/urandom is the output of a CSPRNG? They are both outputs from the same CSPRNG algorithm[1].
Edit: I'm eagerly awaiting the tptacek takedown of this article. Comments like "even a regular user can run: cat /dev/random > /dev/null & cat /dev/zero > /dev/random... entropy will be degraded" do not give me confidence in this guy's understanding of the systems involved. Same with his blatant misreading of RNDZAPENTCOUNT and RNDCLEARPOOL, which simple research[2] reveals only clears the entropy count and does nothing to the underlying entropy pool itself.
Especially because /dev/random's ability to block when it doesn't have enough entropy is dependent on accurate entropy estimation. Since the entropy estimator isn't accurate (it can't be, it's an undecidable problem) there will be attacks possible on the entropy estimator, either causing it to block when it shouldn't (DOS) or output data with insufficient entropy.
I might be mistaken, but doesn't changing /dev nodes require super user rights?
If an attacker has those, he could simply overwrite your libressl binary. Or patch the kernel. Or....
EPERM mode requested creation of something other than a regular
file, FIFO (named pipe), or UNIX ___domain socket, and the caller
is not privileged (Linux: does not have the CAP_MKNOD
capability); also returned if the filesystem containing
pathname does not support the type of node requested.
Of course there is still the theoretical problem that you could be running in a chroot where some unprivileged user has write access to the root and/or /dev so that she can create symlinks or move files around there. I don't think that should be the responsibility of the library to defend against though; but the responsibility of whoever created that chroot dir...
I agree, but it's really theoretical:
If the user has write access to the chroot environment, she can just replace the binary or play tricks with the libraries. No way the (then not even run) binary can defend against that. Didn't try it, but I would guess that subverting crypto is /slightly/ easier if you can run your own code instead of just manipulating the random seeds.
I think the OP is right. The first mistake he mentions is just not reading enough from urandom and thus falling back on unsecure values, which is just sloppy C. Then all the other attack scenarios require the ability to replace /dev/urandom in various insane ways (sparse actual files, symlinks, other devices). It all just seems pretty pointless. Just read /dev/urandom in a loop until you have enough and abort on any other case. That way you assure a secure result as long as the user has a sane environment and abort otherwise.
Lots of errors in this article. It particularly rankles my sensibilities when he says randomness doesn't actually exist and it's just when humans can't track all the variables.
Randomness is much more interesting than that, and while it would make a lot more sense for the sake of classical mechanics, it cannot possibly be explained away so neatly according to Bell's Inequality.
I just didn't explicitly mention global variables because that will always remain a possibility that lurks over everything. Technically, we can never rule them out because it's possible that all the universe and all the events of universe were preordained by one massive global variable, without any particular rhyme or reason for rules and laws for mechanics of local behavior.
The second paragraph of the article is fundamentally wrong:
Now randomness doesn't really exist. When we humans see
something as random, it's only because we don't know or
understand all the details. Therefore, any perceived
randomness on your part is your inability to track all
the variables.
(The currently accepted explanation of) quantum mechanics says otherwise. The essence of quantum mechanics is not certainly but probability. But this annoyed even Einstein, who famously said "God does not throw dice". Einstein was (probably) wrong about this.
Stephen Hawking says:
God does play dice with the universe. All the evidence
points to him being an inveterate gambler, who throws
the dice on every possible occasion. [1]
The first issue he brings up seems legit. Whter it is exploitable or not depends heavily on if an unprivileged account can trigger a read to /dev/urandom to abort early by triggering an interrupt. I don't know Linux internals well enough to know if this is the case, but since this is documented behavior it seems reasonable to concede that there could be some platform where its true.
Everything else seems specious. If you are in an environment controlled by an attacker there is no case where you can reliably generate random numbers. Sure as an attacker that already has root access I could replace /dev/urandom with a link to /dev/zero, but why would I do that when I could just install a kernel module that silently sent me whatever real random seed I decided to give you or patch your process to send the keys that are the end product of that randomness to my self?
Edit: I'm eagerly awaiting the tptacek takedown of this article. Comments like "even a regular user can run: cat /dev/random > /dev/null & cat /dev/zero > /dev/random... entropy will be degraded" do not give me confidence in this guy's understanding of the systems involved. Same with his blatant misreading of RNDZAPENTCOUNT and RNDCLEARPOOL, which simple research[2] reveals only clears the entropy count and does nothing to the underlying entropy pool itself.
[1]: http://www.2uo.de/myths-about-urandom/
[2]: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...