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  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/


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux - Powered by OpenVZ