Date: Thu, 6 Sep 2012 13:03:25 -0700 From: David O'Brien <obrien@FreeBSD.org> To: Dag-Erling =?unknown-8bit?B?U23DuHJncmF2?= <des@des.no> Cc: Arthur Mesh <arthurmesh@gmail.com>, freebsd-security@FreeBSD.org, Doug Barton <dougb@FreeBSD.org>, freebsd-rc@FreeBSD.org, Mark Murray <markm@FreeBSD.org> Subject: Re: svn commit: r239598 - head/etc/rc.d Message-ID: <20120906200325.GA17159@dragon.NUXI.org> In-Reply-To: <86lignot6a.fsf@ds4.des.no> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <20120904220126.GA85339@dragon.NUXI.org> <50468326.8070009@FreeBSD.org> <20120906164514.GA14757@dragon.NUXI.org> <867gs7qcsl.fsf@ds4.des.no> <20120906184400.GF13179@dragon.NUXI.org> <86lignot6a.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 06, 2012 at 09:19:41PM +0200, Dag-Erling Smrgrav wrote:
> David O'Brien <obrien@FreeBSD.org> writes:
> > Dag-Erling Smørgrav <des@des.no> writes:
> > > However, it does not vary from one boot to another, or even from one
> > > machine to another if they run the same FreeBSD version with the same
> > > device.hints and loader.conf on the same hardware configuration.
> > ... and same BIOS version.
> >
> > I found on some Dell desktops and HP servers I looked at that the
> > 'hint.acpi.0' MIB could vary depending on BIOS version, and 'smbios'
> > MIB did vary between systems.
>
> kenv(1) on the machine I'm typing this on produces 2128 bytes, less than
> 1% of which will vary between machines with the same motherboard.
DES,
I am not sure what you are arguing. Are you asking for 'kenv' to be
removed from better_than_nothing() ? Or are you just making sure folks
are aware it is not a source of strong entropy?
Currently 'kenv' does not have a way to display a specific MIB so its
hard to reduce the output to just that which may vary.
'date' has 28 characters of output, well formed in such a way to reduce
the search space. The variance alone in 'kenv' output on the tier-1
vendor machines I inspected had much more than that (> 100 characters).
We could reduce the boiler plate by:
kenv | sed 's/.*"\(.*\)"/\1/'
which reduced 2786 bytes of output to 660 on an HP test machine.
> The UUID is all-zeroes except for the lower 48 bits, which are
> identical to the on-board NIC's MAC address.
I'm seeing
smbios.system.uuid="6c7e35be-5599-db11-ae96-39bc833c4d3c"
-and-
smbios.system.uuid="44454c4c-5200-1053-804a-b7c04f594631"
I already acknowledged that smbios output can be crappy on some systems.
The MAC is not in the 'kenv' output, so I'm not sure how that statement
applies.
> The BIOS version consists of two
> characters ("F8") and a release date ("01/08/2007").
> If the attacker
> knows what motherboard I have, he can easily figure out the handful of
> possible BIOS revisions and release dates, and the first 24 bits of the
> MAC address (00:16:e6).
I already said an attacker could have a local login on the system.
That would give them full knowledge of the kenv output.
Same attacker can figure out the 'date' output from uptime, etc...
> > I'm not saying 'kenv' is perfect, but it was something I found in
> > /[s]bin that varied between systems so it was a good replacement for
> > one of the 'pas' runs.
>
> ...except ps(1) varies between reboots and over time, especially if you
> include fields like majflt, minflt, nivcsw and nvcsw, and to a lesser
> extent systime and usertime (it would help if they had greater
> resolution); whereas kenv(1) does not and can be identical or nearly so
> on multiple machines.
Does 'ps' vary that much across the two invocations that we had in
'initrandom'? Please post a diff to back up any "yes" answer.
We already have an invocation of 'ps'. Please suggest a *different*
command invocation.
--
-- David (obrien@FreeBSD.org)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120906200325.GA17159>