Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
Re: nfsbug, bugssmbresearch.att.com
Tue, 07 Feb 95 10:52:31 EST
- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Mark Graff : "Re: Solaris 2.3 ndd bug"
- Previous message: Christopher Klaus: "Tcp Seq Vendor Update"
- Maybe in reply to: Martha Lanatte: "nfsbug, bugs"
> The best you can do is get a non-broken fsirand and rerun it on > your system. This will randomize the numbers nfs uses for file hand les. > After doing this any system currently accessing filesystems exported > from your host will have to remount to get valid file handles. By non-broken, do you mean one that does not use the same seed for each randomizaton, or something complete different? Older versions of fsirand used a very non-random seed for the random number generation; you could guess it in a few hundred tries, as a rule. > How can you use the filehandle? You could stick it in a variable > and pass it off to nfs to request operations be done on the file > associated with the handle. Anyone care to elaborate? NFS operations are all based on file handles. To look up a file name in a directory, the client passes the server the directory's file handle and the name of the component being searched for; the server returns the file handle for that component. Read and write operations use a file handle to specify which file is to be modified. In other words, having a file handle is everything. In normal operation, clients mount remote file systems by talking to mountd. Assuming the (inadequate) checks succeed, the file handle for the root inode of that file system is passed back to the client; it's used for doing directory tree walks to reach any file in that subtree. Thus, someone who can guess the file handle of the root inode can bypass most of the security checking. I should note here that file handles are supposed to be opaque 32 byte quantities to the client. In practice, they contain things like the device number (in the server's space, not the client's), the i-node involved (which for the root i-node is always 2), and some random quantity. It's the random quantity that's the trouble here -- it isn't random.