Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 14 Mar 2013 10:32:59 +0400
Subject: Re: Linux kernel + devtmpfs automount == insecure /dev/{,u}random mode

On 13-Mar-2013 15:54:15 +0400, wrote:

 > Yes, I've found that while investigating the possible impact. Also,
 > the random.c doesn't use the data directly, but instead hashes it.

And that has some impact: the malicious (or just curious) unprivileged
user may run flood the devices with garbage, and the kernel will spend
resources hashing it.

Try this: `dd bs=1M if=/dev/zero of=/dev/urandom`

On a Core i5-2400 3.10GHz CPU, only 16 processes running for several
minutes result in all cores loaded at 99% and the load average of 20.
My workstation has survived the experiment, but heavy-loaded servers
may dislike that :-)

 > But my opinion stays exactly the same: devices should be 0644, and
 > only trusted random data sources should be used to add entropy to
 > the pool via add_device_randomness().
 > So, I'll just restrict the access to /dev/{,u}random locally :-)

... and recommend others do the same.

Alexey V. Vissarionov aka Gremlin from Kremlin <gremlin ПРИ gremlin ТЧК ru>
GPG key ID: 0xEF3B1FA8, keyserver: hkp://
GPG key fingerprint: 8832 FE9F A791 F796 8AC9 6E4E 909D AC45 EF3B 1FA8

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.