From owner-freebsd-security@FreeBSD.ORG Mon Sep 10 20:03:22 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 28E82106564A; Mon, 10 Sep 2012 20:03:22 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 99ECC14DDAA; Mon, 10 Sep 2012 20:02:46 +0000 (UTC) Message-ID: <504E4765.1020909@FreeBSD.org> Date: Mon, 10 Sep 2012 13:02:45 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> <20120903214638.GO1464@x96.org> <50453686.9090100@FreeBSD.org> <20120904220754.GA3643@server.rulingia.com> <20120906174247.GB13179@dragon.NUXI.org> <20120906230157.5307a21f@gumby.homeunix.com> <20120906224703.GD89120@x96.org> <20120907015157.GA29497@server.rulingia.com> <20120910135218.GA68128@dragon.NUXI.org> <504E343A.4020802@FreeBSD.org> <86pq5tu1zr.fsf@ds4.des.no> <504E3DAB.3090000@FreeBSD.org> <86fw6pu0l0.fsf@ds4.des.no> In-Reply-To: <86fw6pu0l0.fsf@ds4.des.no> X-Enigmail-Version: 1.4.4 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Arthur Mesh , freebsd-rc@freebsd.org, freebsd-security@freebsd.org, RW , Xin Li Subject: Re: svn commit: r239569 - head/etc/rc.d X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 20:03:22 -0000 On 9/10/2012 12:42 PM, Dag-Erling Smørgrav wrote: > Doug Barton writes: >> If the problem with replay attacks is as bad as Arthur suggest it is, >> it should be visible in far less than a million tries. > > I was exaggerating a bit - but my reasoning was that since it hasn't > blown up in our faces yet, it's probably subtle enough to require a > large number of samples. ... or doesn't exist at all. :) And even if it did exist, but requires thousands of reboots to see a duplicate, then for all intents and purposes it still doesn't exist for any reasonable use case given that after the system has been up for more than 5-10 minutes with a typical load there will have been way more than sufficient hardware entropy harvested to make the internal state "unique" for all practical purposes. If I were Arthur, here is how I would test the "replay attack" assertion: 1. Install a virgin system with everything as it was before David's first commit, and let it run for 24 hours with all the defaults intact. Ideally, have it do something over the network periodically to make sure that some kind of entropy is harvested from the network drivers. Run 'find / -name SASLKASDJKL' to make sure you get some from the disk drivers too. 2. Disable the cron job for the /var/db/entropy script, and comment out the writing of /entropy at shutdown time in /etc/rc.d/random. 3. Write a script to reboot, and once the system is fully booted do 'dd if=/dev/random of=saved-random-out.$i count=4096' then reboot again immediately. Values of i from 1 to 10,000 ought to do it. 4. sha256 the saved-random-out files and see how many duplicates there are. This is simple to automate, and won't cost anything but a little time to set it up. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909)