linux security - Apr 1997 - /dev/random and MAKEDEV-C-1.6

[Note: this has already been sent to comp.os.linux.announce.]

-----BEGIN PGP SIGNED MESSAGE-----


It has come to my attention that the recent 1.6 release of MAKEDEV-C
inadvertently created /dev/random and /dev/urandom with the wrong
permissions.

/dev/random and /dev/urandom should look like this:

crw-r--r--   1 root     system     1,   8 Feb 21 14:42 /dev/random
crw-r--r--   1 root     system     1,   9 Feb 21 14:42 /dev/urandom

If they do not, please do "chmod 644 /dev/random /dev/urandom".

 **** This has potentially serious security implications.
 **** Unrestricted write access to /dev/random and /dev/urandom
 **** makes them cryptographically worse than useless.


If you have MAKEDEV-C-1.6 installed please get MAKEDEV-C-1.6.1, which
has just been uploaded to Sunsite and should appear in
/pub/Linux/system/admin. It can also be gotten from
ftp://ftp.hcs.harvard.edu/pub/linux/makedev.

Alternatively apply the following patch. You do not need to recompile
the makedev binary itself, but you do need to update the installed
devinfo and makedev.cfg files.

If you don''t have pgp and don''t know how to fix a patch that
pgp has
signed, you can get the patch from the hcs ftp site, although I did
not upload it to sunsite.

If you have questions or concerns, feel free to mail me.

   David A. Holland
   dholland@hcs.harvard.edu


diff -r -u -N makedev-1.6/README makedev-1.6.1/README
- --- makedev-1.6/README	Sat Feb  1 02:32:23 1997
+++ makedev-1.6.1/README	Thu Apr 24 10:04:19 1997
@@ -6,6 +6,11 @@
 /etc/devinfo. The config file is intended to be fairly human-readable,
 as well as machine-readable.

+New in release 1.6.1:
+
+Correct permissions on /dev/random and /dev/urandom. This has security
+implications.
+
 New in release 1.6:

 The configuration files have been updated to reflect kernel 2.x, and
diff -r -u -N makedev-1.6/devinfo makedev-1.6.1/devinfo
- --- makedev-1.6/devinfo	Sat Feb  1 02:22:15 1997
+++ makedev-1.6.1/devinfo	Thu Apr 24 09:59:11 1997
@@ -104,8 +104,8 @@
        	zero (public) : 5
 	core -> "/proc/kcore"
 	full (public) : 7
- -	random (public) : 8
- -	urandom (public) : 9
+	random (publicro) : 8
+	urandom (publicro) : 9
 }
 block (std, 1) {
 	initrd (disk) : 250
diff -r -u -N makedev-1.6/makedev.cfg makedev-1.6.1/makedev.cfg
- --- makedev-1.6/makedev.cfg	Sat Feb  1 02:23:58 1997
+++ makedev-1.6.1/makedev.cfg	Thu Apr 24 09:58:53 1997
@@ -4,6 +4,7 @@

 class default:	root	system	0640
 class public:	root	system	0666
+class publicro:	root	system	0644
 class system:   root	system	0660
 class kmem:	root	kmem	0640
 class tty:	root	tty	0620

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBM198qTx1dyEHyT51AQHh3QP/ezmJbmkPI7FkhPY85hFWGkJwV9L9cb+9
ajoH+uxN21rlvkD509T4Rk+bS0QesUNjyUdIB6qtj2LQCsvQF1ZxlCu7uU3iFNHN
d1CAU4zb4jLEsJSD54yDNS3bcPPEt9xU4t/GWgNdk4WbbhokZBm6kllfpzRWENPK
yavCvcwXeJI=Qen2
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----

   From: David Holland <dholland@hcs.harvard.edu>
   Date: Thu, 24 Apr 1997 11:36:30 -0400 (EDT)

   It has come to my attention that the recent 1.6 release of MAKEDEV-C
   inadvertently created /dev/random and /dev/urandom with the wrong
   permissions.

    **** This has potentially serious security implications.
    **** Unrestricted write access to /dev/random and /dev/urandom
    **** makes them cryptographically worse than useless.

Sorry, but this simply isn''t true.  I wish someone had contacted me
before sending out the alarums to c.o.l.a.  [ To the c.o.l.a. moderator,
if the alert has already been published, if you could send this out as
well, I''d be grateful.]

Writes to /dev/random and /dev/urandom are *mixed* into the entroy
pool.  If you don''t know the state of the pool before the write, you
don''t know anything about the state of the pool after the write.  We
use
a complex (but invertible, so that no state is lost) mixing function
that involves the use of XOR and a twisted LFSR so that you get good
mixing even if you feed all zero''s into /dev/random.  A critical design
property of /dev/random''s mixing algorithm is that even if the attacker
knows some of the values that are mixed into the pool, it doesn''t
detract from the entry of the unknown values which are mixed in.
(To those of you who are wondering SHA is used only on the output side
of the random number generator, when we wish to extract random numbers.)

Also, note that writes to /dev/random do not increase the entropy count
of the pool, because of the possibility that an unprivileged attacker
might be mixing in known values to the pool.  In this case, the entropy
will not increase, but neither does it increase either.

There is an ioctl() which you have to use if you want to increase the
entropy count, and this requires root access.  This is for the
possibility of user-mode daemons that might sample /dev/audio, or some
such.  Note that if you write such a daemon, you will need to do your
own analysis, (probably involving FFT''s) in order to properly estimate
the amount of randomness in your /dev/audio input.  (i.e., you need to
account for the non-random parts of the /dev/audio stream, such as that
which is attributable to the 60Hz or 50Hz hum.)

						- Ted



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.2, an Emacs/PGP interface

iQCVAwUBM2DGakQVcM1Ga0KJAQFtCAP9FDleE60dpk63kxUzwSwuvhPHVliWWXRd
hxBJRPiwm5kYqUPrryAPw/EpYwqMfYzcRoc9JYwB888OVDu8T6hLgjgwvNCfivQZ
jd6Z89K0G+Un7jxyLMqU1xdZeOVQVrx81nSX1av+cs0DfTal8Kf2RN6NkOdZ0w4U
GX92c2njDd8=MvzW
-----END PGP SIGNATURE-----