1. 15
  1.  

  2. 9

    How do you even know if /dev/(u)random is random in the first place? This may sound like a strange question, but it isn’t. You can’t just trust a file because of it’s path. Consider an attacker ran the following:

    Now both random devices are actually large sparse files with known data. This is worse than not having access to these files, in fact, the attacker is able to provide you with a seed of his own choosing!

    This seemed like a strange thing to even mention. In what environment could an attacker possibly control what comes out of the file */dev/urandom" but not have full control over everything else in the environment, like loading an LKM that keeps /dev/urandom as a device but spits out zeroes? I mean I guess if you are chroot()ing to some known valid path but somehow have such screwed up file permissions that an attacker was able to leave that bogus file beforehand, but if that happened I’d also assume the attacker could do much worse than screw up your randomness.

    1. 5

      “A good idea with bad usage” could describe the whole blog series I think. There’s a few good gotchas mentioned, but then it kind of jumps the shark and turns into “42 deadly facts you need to know about tap water.”

      1. 2

        The blog post talks about replacing “/dev/urandom” but a process could be tricked into opening a file that is not “/dev/urandom” but a regular file that is controlled by another unprivileged process.

        1. 1

          I had that exact same though, even if you used syscalls if someone’s got control over your stuff, it could put a debugger or something over it. Though there might be environments (I think OpenVZ and its “para-virtualization” thing) where with the right exploit at the same time you might get compromised just enough to do some minor changes and allow for a broken /dev/urandom to get into your system.. if that makes sense… ?

        2. 4

          Let me be the first to come out and say it: I just spent all morning updating code I had written which was using urandom incorrectly. It never occured to me that any of this could happen.

          With all this extra code, my bcrypt wrapper is now over half the length OpenBSD’s bcrypt implementation. Stupid.

          1. 4

            The correct way to use /dev/urandom is to read bytes from it. You should, practically speaking, ignore everything in this blog post. It amounts to a whole bunch of potential exploits and workarounds which require enough privileges to do far worse things than mess with the kernel random number generator (any process with sufficient privileges to replace /dev/urandom could much more profitably spend its time simply reading generated key material out of your process’s memory, for example).