Re: RPC protocol problem?

[jsz () ramon bgu ac il (jsz)]

> "In the previous message, Doug Davis said..."
> > The real question is one of; how to beat vendors into fixing the
> > problems reported by it.. (grumble grumble)...
>
> Or failing that, has anybody devised a way to:
>
> A: use LD_PRELOAD to replace the random() (or srandom()) or whatever function
> fsirand calls with one that ignores the passed init seed, and produces its
> own, to make it work right...?
>   or
> B: Make available sources for a replacement fsirand that will work on SunOS
> and other affected OS's that one can build and run.

There has been a patch for it, for over 2 years.

1063470 Non-random file handles can be guessed, leading to security hole.
NFS jumbo patch fixes it.


>   or
> C: I resorted to letting the PIDs get way up there, say over 10,000 then
> kicked the system down to single-user, did a umount -a, and ran it on all
> the filesystems (except /, and /usr, of course).  Making sure it wasn't
> shut down and rebooted, the PIDs just continue from what they were when
> it was up in multi-user.
>
> So, all I get in nfsbug output is the UID bug (which goes away if I don't
> export as root, but sometimes that is needed).  I wonder if anybody
> has put together the affected module from non-restricted sources,
> so people can fix it?  I know that Suns NFS jumbo patch doesn't
> affect the UID bug, as it is still there.  I have no idea if it
> fixes the fsirand prolbem or not...

Yes, it does fix the fsirand problem. UID bug? you mean the uid_t bug,
uid/gid values are supposed to be 32 bits wide, while SunOS's uid_t is
16, it affects all OS's that have uid_t == 16 bits, eg IRIX, etc have
this problem too, there is a patch for it, as well.

1095935 
        NFS server in which a client presenting a 32-bit uid in which 
        the 16 low-order bits are 0 gets interpreted as root on the server.