Please note that in spite of my @freebsd.org address, I do not purport to
speak for the project here. That said, this isn't really a security@ issue,
it's more of a freebsd-stable@ issue, for future reference. And FYI, I'm
also combining two of your posts so that hopefully we can put this issue to
rest.
Michael Scheidell wrote:
> I was doing some regression testing in 5.5:
Not sure what your purpose is here. The 5.x branch is likely to die with
5.5, so if you're looking for a branch for your enterprise to use going
forward, you're better off testing in 6.x. If you have other intentions for
doing this testing, it would be useful to know them so that we can better
answer your questions.
> Specifically testing booting up a 'virgin' hard disk from a clean install.
>
> I was testing what happened if the 300 second timeout happened vs
> hitting <return> for 'fast+insecure' startup and punching in a bunch of
> random garbage.
>
> I found that for some reason, on a 2.4Ghz Celeron, the 'sysctl -a' and
> 'date' seeding for 'fast+insecure' seemed to do nothing unless I typed
> in at least 3 lines of random keystrokes.
That's more or less the expected behavior.
> ie: /etc/rc.d/sshd start WONT, it doesn't generate ssh keys in /etc/ssh
> and ssh won't start.
Also expected.
> Is there something in /dev/random that won't init if it isn't random enough?
Yes. When the Yarrow PRNG was introduced back in the 5-CURRENT days, there
were extensive references posted to the design docs. You might want to read
the random(4) man page as well.
> (if doing this from an unattended bootup, expecting the 300 second
> timeout, I find that sshd does not start!)
I cannot imagine a scenario where a competent system administrator would do
a clean install on a machine, reboot it, and then just walk away without
first testing to see that all expected services (especially sshd) were
working according to plan. If you can envision such a situation, please
describe it in more detail.
> In a remote location, with no head, no monitor, its hard trying to
> figure out just WHY 'system won't boot'.
> (it booted, but sshd didn't start!)
This is what serial consoles and KVMs are for.
> it might feed it LATER, saving to /var/db/entropy,
I _think_ you understand how this works, but just to be clear, the "random"
data in /var/db/entropy is output from /dev/random after it has already been
seeded. This stuff is then fed back into /dev/random at boot time in order
to speed up the process of initializing the PRNG.
> Not sure why the reluctance to even acknowledge that there could be a
> minor fix/patch that could prevent dead box and a ${miles=hundreds) trek
> to bring it back.
I don't think anyone is saying "there cannot be a problem," I think that
we're waiting for you to describe what FreeBSD problem you'd like us to fix,
and/or what fix you're proposing. The confusion is understandable if you did
not previously know how things were supposed to work, but hopefully this
post clears that up for you.
> Only two workarounds that I know of:
> #1, put in more than 3 lines of garbage on console.
That works, and is in fact (as you surmised) the intended workaround to the
problem you describe. Why is this not sufficient for you?
> #2, put in more than 5 packets of garbage from ethernet
> (which, acknowledged: if hacker is trying to seed known data to this
> box, he could feed it known data)
Well, the bits of entropy gathered from the system are not fed directly into
the PRNG, they are massaged a bit first. So it would not be quite that easy
for an attacker to manipulate things. You might want to read up on how
Yarrow works.
hope this helps,
Doug
--
This .signature sanitized for your protection
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
