Full Disclosure mailing list archives

owning /dev/[u]random


From: aliver () hexeris mine nu (Aliver)
Date: Wed, 11 Sep 2002 18:15:56 -0600

        While doing some code auditing I got to thinking about
known-plaintext attacks against various ciphers when /dev/random or
/dev/urandom have been comprimised. A quick search on google doesn't turn
much up. However, I'm curious if anyone knows of a thread somewhere where
folks have discussed the implications of such a thing, and perhaps
formulated a strategy to attack any much-used applications like those
linked against openssl and using one of the ciphers therein.
        I'm thinking mainly of Solaris systems (before solaris 9) with no
SUNWSki package where someone might be able to write, say only 4 bytes of
data to /dev/random using a race condition or other such trickery. There
are a few cases (like padding ciphertext in a block cipher) where this
might be enough of a toehold to try a known-plaintext attack. If the
implications were serious enough, an attacker who owns a machine may
choose _only_ to alter the /dev/random or /dev/urandom devices for some
nefarious purpose. Of course it'd probably be much more fruitful to simply
trojan all the shells. However, it's pretty tough to use AIDE or Tripwire
on /dev/random or /dev/urandom (So, I'm guessing that they don't check to
make sure that these are actually character devices). So, it might be
pretty a pretty sneaky trick to own the machine, add your known-plaintext
in place of /dev/random or /dev/urandom, then put the box back like it was
before anyone checks the MD5 hashes.

Before anyone flames me, I'd like to use a tactic pioneered by RFP, and
safe the troll some time:

1. I have a small penis
2. I don't know shit.
3. I'm not a _true_ hacker/blackhat/whatever.

aliver
--
Question: Is it better to abide by the rules until
they're changed or help speed the change by breaking them?



Current thread: