Re: Bad PRNGs revisted in FreSSH

[tls () REK TJLS COM]

> The newly announced FreSSH, when there is no
/dev/urandom available,
> uses a `fallback' to seed its PRNG that consists
of:
>                         int numfs, whichfs = 0;
>                         struct statfs *mntbuf;
>                         numfs =
getmntinfo(&mntbuf, MNT_NOWAIT);
>                         while (whichfs < numfs)
{
>                                
ssh_rand_feed((void *) mntbuf,
>                                    
sizeof(struct statfs));
>                                 memset(mntbuf,
0, sizeof(struct statfs));
>                                 mntbuf++;
>                                 whichfs++;
>                         }
>
> I don't think I need to tell people on this list
why that's absolutely
> horrible; I'm just pointing out that code is
still released today with
> crap like this.  I would have thought we'd
learned this lesson years
> ago with the AFS, krb4, Netscape, et al
vulnerabilities.


YOu know what?  I happen to agree with you -- so
far as this not being a particularly lovely way to
seed a PRNG goes.  Due to a miscommunication, some
documentation of why one *really* oughtn't use
this fallback method wasn't included in the public
FreSSH distribution -- thankfully, since just
about everyone in the world *does* have a
/dev/random (whatever name it's called by; this
code is in an OS-dependent source file that has
the appropriate name for the OS in question in it)
just about nobody does get stuck with this. 
However, some more notes on what they get stuck
with:

* worst-case, it degenerates to the internal
seeding of the OpenSSL PRNG, even if we fed it
_nothing_ else at all.  OpenSSL doesn't really
suck about this.

* it doesn't _quite_ degenerate to just the code
you pasted above; several timings are mixed in,
not just at seed time but over the course of the
daemon's run.

* the alternate cryptographic module used by
RedBack, who ship a non-Unix port of FreSSH in
their products, uses a *hardware* randomness
source; so, they don't lose.

* I agree with you that the code pasted above is
insufficient to say the least, and this will get
fixed.  However, if you have /dev/random, it
basically makes no difference; and given the
highly constrained set of platforms FreSSH runs on
at the moment, that basically means "it makes no
difference".  On the platforms that don't have
/dev/random, the code above doesn't even
*compile*.

Thank you for pointing this out, however.  The
fact that a number of additional command timings
just above the code you pasted got commented out
at a relatively late date in the 0.8 release cycle
doesn't help any, nor does the lack of good
documentation.

As we've said everywhere we've had the chance,
FreSSH 0.8 is still very young software, and we
urge people to *look at it* before *using it*.  If
this is the worst problem anyone finds, I will be
glad; which is not to say that the software was
not written carefully, but it is also not to claim
that I and the other authors don't make mistakes.

Thor