full-disclosure - owning /dev/[u]random

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <Pine.SGI.4.44.0209111801370.1524-100000@hexeris.mine.nu>
From: aliver at hexeris.mine.nu (Aliver)
Subject: owning /dev/[u]random

	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?