Subject: Re: NFS and reserved ports
To: Jim Reid <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 03/24/1997 08:14:57
Jim Reid <firstname.lastname@example.org> writes:
> >>>> "Jonathan" == Jonathan Stone <jonathan@DSG.Stanford.EDU> writes:
> then crypting them with a key derived by something supplied by the
> client at mount time. [Lots of handwaving here.] The server could
> cache these for a while to save on per-request crypts.
<Boggle> If the filehandles are ephemeral, how do you propose to
handle server crashes? If they're not ephemeral, where do you keep
> Jonathan> Historically, didn't the original SunOS implementation
> Jonathan> get by without high-quality randomness? How good was
> Jonathan> that? Anyone know of good studies in breaking SunOS 4.x
> Jonathan> filehandles?
> It got by. It wasn't much good. See the nfsbug program. It's up for
> ftp at CERT I think. It was able to guess SunOS 4 file handles and
> anything else which used the same/similar fsirand code. The basic
> problem was a poor random number generator tied to an easily guessed
> initialisation vector.
So, we have a better PRNG, and we can set the intialization vector
from a high-quality random number source (/dev/random), at least when
/dev/random exists. That's what I was assuming as a baseline.
How good is that, given that the inodes and and their generation
numbers get exposed?