bugtraq - Re: Ubuntu: reseed(8), random.org, and HTTP request

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 6 Jul 2011 12:41:55 -0700
From: Michal Zalewski <lcamtuf@...edump.cx>
To: noloader@...il.com
Cc: Full Disclosure <full-disclosure@...ts.grok.org.uk>,
	BugTraq <bugtraq@...urityfocus.com>
Subject: Re: Ubuntu: reseed(8), random.org,
	and HTTP request

> Ubuntu's reseed(8) can be used to seed the PRNG state of a host. The
> script is run when the package installed, and anytime su executes the
> script.
>
> reseed(8) performs a unsecured HTTP request to random.org for its
> bits, despite random.org offering HTTPS services.

This resulted in a couple of discussions elsewhere, but as weird the
idea of retrieving a seed from the Internet is (over HTTPS or not),
this particular use is probably (unintentionally) harmless.

Writing to /dev/[u]random does not replace the existing entropy pool,
and merely mixes some new data in. Therefore, the script does not
reduce the quality of the kernel PRNG if you already have some entropy
collected, even if the returned payload is completely bogus. The only
effect it may have is improving entropy if you don't have any, or not
doing anything useful (if connection fails, or predictable data is
returned).

I initially thought this is still bad news, because you don't want the
kernel to think it has more entropy than in reality (thus not blocking
/dev/random reads, etc) - but the write() performed by this code also
does not affect the entropy estimate by the virtue of not doing
RNDADDTOENTCNT or RNDADDENTROPY ioctls. So, it should be OK.

The use of HTTPS is a red herring (and establishing HTTPS without any
real entropy available is tricky anyway). A more significant concern
is that the ownership or quality of random.org may change. But in this
case, it simply renders this effort a nominally harmless no-op.

/mz

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/