From owner-freebsd-security@FreeBSD.ORG Fri Sep 14 15:05:30 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 738F31065673 for ; Fri, 14 Sep 2012 15:05:30 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from gromit.grondar.org (grandfather.grondar.org [93.89.92.32]) by mx1.freebsd.org (Postfix) with ESMTP id 2E8658FC16 for ; Fri, 14 Sep 2012 15:05:30 +0000 (UTC) Received: from uucp by gromit.grondar.org with local-rmail (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TCXNH-0004Sp-1Z for freebsd-security@freebsd.org; Fri, 14 Sep 2012 16:00:07 +0100 Received: from localhost ([127.0.0.1] helo=groundzero.grondar.org) by groundzero.grondar.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TCXN0-000NFT-7I; Fri, 14 Sep 2012 15:59:50 +0100 To: "Bjoern A. Zeeb" In-reply-to: References: <50453686.9090100@FreeBSD.org> <20120911082309.GD72584@dragon.NUXI.org> <504F0687.7020309@FreeBSD.org> <201209121628.18088.jhb@freebsd.org> <5050F477.8060409@FreeBSD.org> <20120912213141.GI14077@x96.org> <20120913052431.GA15052@dragon.NUXI.org> From: Mark Murray Date: Fri, 14 Sep 2012 15:59:50 +0100 Message-Id: Cc: Arthur Mesh , Ian Lepore , Doug Barton , David O'Brien , freebsd-security@freebsd.org, RW 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: Fri, 14 Sep 2012 15:05:30 -0000 "Bjoern A. Zeeb" writes: > 1) continue to over-[fs]eed as we always did (seems out of question, > no improvement) See below. Solutions are very possible. > 2) compress (as in gzip) the input of better_than_nothing (multiple > people objected, no literature, questionable outcome, speed, still not > great control over how much data we seed) Not a bad idea, but by better handling of stuff written to /d/r this can be made much more useful. Compressing is a very useful entropy distiller in its own right, but is slow. > 3) hash (arch dependent?) the entire input of better_than_nothing in > the shell script (at least a good idea on how much data we seed) Yup; same advantages as compression, but predictably sized output. Like compressing, its slow. Better handling of files witten to /d/r will also help massively. > 4) hash (arch dependent?) individual parts of better_than_nothing in > the shell script (seed more and still know how much data we'd seed) Doable. Useful. > 5) send all data to the kernel but XORing the data together on > overflow in the kernel (can control when buffer full and only then > take action when needed, indepedent on how seed data is chosen, > withdrawn) I've already coded this up :-) (well, similar). This is the "improved file handling" that I was thinking of. Note that I only do it for writes to /d/r, and not for all entropy harvesting. It still largely kills the entropy swamping, and while an attacker can subvert this, the attack would be obvious. I'll send patches (untested) in a couple of hours for discussion. > 6) send all data to the kernel but XORing the data + counter value > together on overflow in the kernel (can control when buffer full and > only then take action when needed, indepedent on how seed data is > chosen, but why XOR?) Variation on above. > 7) send all data to the kernel and hash (arch dependent?) it + counter > value into the buffer on overflow, as in b[n] = H(b[n] + c + i[n]) in > the kernel (can control when buffer full and only then take action > when needed, indepedent on how seed data is chosen, uses standard > technology) Variation on above. M -- Mark R V Murray Pi: 132511160