I was doing some regression testing in 5.5: 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. ie: /etc/rc.d/sshd start WONT, it doesn't generate ssh keys in /etc/ssh and ssh won't start. Is there something in /dev/random that won't init if it isn't random enough? (if doing this from an unattended bootup, expecting the 300 second timeout, I find that sshd does not start!) After doing some testing, it appears that (at least with the combination of a 2.4Ghz Celeron and 5.5) that it takes at least three lines of random data, added to the output of sysctl -a and date to seed /dev/random. (as per this in /etc/rc.d/sshd: read -t ${timeout} junk echo "${junk}" `sysctl -a` `date` > /dev/random I can find no other explanation to the results of my tests: This removes keys: /etc/rc.d/sshd stop rm /etc/ssh/*key* /etc/rc.d/sshd start tests: #1, allow 300 second timeout: remove keys, restart sshd: /etc/rc.d/sshd start let it sit for 300 seconds. No error messages, but sshd doesn't start, and there are no keys in /etc/ssh #2, one line of random test (same results as above) #3, two lines, etc #4, three lines. Now, I get the messages telling me that ssh_keygen has created keys, and there are keys in /etc/ssh I also find that by adding this to the random seeding that it will work with <return> or 300 second timeout: read -t ${timeout} junk echo "${junk}" `sysctl -a` `date` `tcpdump -xs1500 -c 5` > /dev/random Yes, I know, but even ;lj;lkj;lj;ljjl on the keyboard isn't all that random, but my issue is not being able to remotely access a virgin system with ssh. Sometimes these are headless pizza boxes, buried deep in the bowels of some data center. Has anyone else run tests like this? (I suppose the -c value in tcpdump could be random as well '-=) using: count = `date "+%S"` 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!) There is enough random[pun intended] things that can happen when you install a new system, that I would like to try to eliminate one of them. -- Michael Scheidell, CTO SECNAP Network Security / www.secnap.com scheidell@secnap.net / 1+561-999-5000, x 1131
--- Michael Scheidell <scheidell@secnap.net> wrote:> I was doing some regression testing in 5.5: 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. > > ie: /etc/rc.d/sshd start WONT, it doesn't generate ssh keys in /etc/ssh > and ssh won't start. > > Is there something in /dev/random that won't init if it isn't random enough? > > (if doing this from an unattended bootup, expecting the 300 second > timeout, I find that sshd does not start!) > > After doing some testing, it appears that (at least with the combination > of a 2.4Ghz Celeron and 5.5) that it takes at least three lines of > random data, added to the output of sysctl -a and date to seed /dev/random. > > (as per this in /etc/rc.d/sshd: > read -t ${timeout} junk > echo "${junk}" `sysctl -a` `date` > /dev/random > > I can find no other explanation to the results of my tests: > > This removes keys: > /etc/rc.d/sshd stop > rm /etc/ssh/*key* > /etc/rc.d/sshd start > > tests: > > #1, allow 300 second timeout: > remove keys, restart sshd: /etc/rc.d/sshd start > let it sit for 300 seconds. > No error messages, but sshd doesn't start, and there are no keys in /etc/ssh > > #2, one line of random test > (same results as above) > #3, two lines, etc > > #4, three lines. > Now, I get the messages telling me that ssh_keygen has created keys, and > there are keys in /etc/ssh > > I also find that by adding this to the random seeding that it will work > with <return> or 300 second timeout: > > read -t ${timeout} junk > echo "${junk}" `sysctl -a` `date` `tcpdump -xs1500 -c > 5` > /dev/random > > Yes, I know, but even ;lj;lkj;lj;ljjl on the keyboard isn't all that > random, but my issue is not being able to remotely access a virgin > system with ssh. Sometimes these are headless pizza boxes, buried deep > in the bowels of some data center. > > Has anyone else run tests like this? > > (I suppose the -c value in tcpdump could be random as well '-=) using: > > count = `date "+%S"` > > 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!) > > There is enough random[pun intended] things that can happen when you > install a new system, that I would like to try to eliminate one of them. >I think that during the first reboot after a fresh install the kern.random.sys sysctl settings are already orderly before rc.d/sshd is called... If yes, then sending some pings should do the trick... Or not? I mean: NETWORKING should already be provided at that point... Btw.: __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
> -----Original Message----- > From: R. B. Riddick [mailto:arne_woerner@yahoo.com] > Sent: Tuesday, August 08, 2006 4:12 AM > To: Michael Scheidell; freebsd-security@freebsd.org > Subject: Re: seeding dev/random in 5.5 > > I think that during the first reboot after a fresh install > the kern.random.sys sysctl settings are already orderly > before rc.d/sshd is called... > > If yes, then sending some pings should do the trick... Or > not? I mean: NETWORKING should already be provided at that point...I am not sure I understand what you are saying in the context of my question.
--- Michael Scheidell <scheidell@secnap.net> wrote:> > I think that during the first reboot after a fresh install > > the kern.random.sys sysctl settings are already orderly > > before rc.d/sshd is called... > > > > If yes, then sending some pings should do the trick... Or > > not? I mean: NETWORKING should already be provided at that point... > > I am not sure I understand what you are saying in the context of my > question. >I mean: Instead of changing a rc.d script u or ur friend could just send some pings to the deeply buried box... -Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
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
> -----Original Message----- > From: owner-freebsd-security@freebsd.org > [mailto:owner-freebsd-security@freebsd.org] On Behalf Of Kevin Day > Sent: Tuesday, August 08, 2006 4:59 PM > To: Doug Barton > Cc: freebsd-security@freebsd.org > Subject: Re: seeding dev/random in 5.5 >Yes, the install I had to do in amsterdam, translating dutch to english and back is the one I was concerned abot.> >Maybe sysinstall could be collecting entropy during the installation> and use that for an initial seed if the timeout happens? It wouldn't > be perfect, but it'd be better than killing ssh. >Or use my idea of collecting 5 to 10 packets using tcpdump!