Re: [Full-disclosure] 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
Re: [Full-disclosure] Ubuntu: reseed(8), random.org, and HTTP request
[ But for what it's worth, I am willing to bet that the script was added without analyzing these subtle considerations, and that makes it somewhat scary on its own accord. ] /mz
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. The Ubuntu Security Team took no interest when contacted by email (no reply); the point of contact listed in the man pages took no interest when contacted by email (no reply); and a launcher bug report was not acted upon (https://bugs.launchpad.net/ubuntu/+source/reseed/+bug/804594).
Re: [Full-disclosure] Ubuntu: reseed(8), random.org, and HTTP request
On Tue, Jul 5, 2011 at 9:04 PM, Jeffrey Walton noloa...@gmail.com wrote: 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. ... someone thought this was a good idea. [an entropy pool remotely biased by MitM attacker, maybe?] reseed(8) performs a unsecured HTTP request to random.org for its bits, despite random.org offering HTTPS services. https doesn't help if your host entropy pool is poorly seeded. [SSL/TLS needs entropy for authenticity/privacy.] The Ubuntu Security Team took no interest when contacted by email (no reply); the point of contact listed in the man pages took no interest when contacted by email (no reply); and a launcher bug report was not acted upon (https://bugs.launchpad.net/ubuntu/+source/reseed/+bug/804594). you're surprised? [you must be new around here!]
Re: [Full-disclosure] Ubuntu: reseed(8), random.org, and HTTP request
On Wed, 2011-07-06 at 00:04 -0400, Jeffrey Walton wrote: 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. Ubuntu's response can be found in the bug: https://launchpad.net/bugs/804594 -- Jamie Strandboge | http://www.canonical.com signature.asc Description: This is a digitally signed message part
