OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq archives for 2nd quarter (Apr-Jun) 1994: More on NFS hacking

More on NFS hacking

Jeremy Epstein -C2 PROJECT (jepsteincordant.com)
Mon, 18 Apr 1994 08:45:03 -0400 (EDT) 

With all this discussion of NFS hacking based on the weakness
of fsirand(), I'd point out that if there are *old* machines
out there it's much easier than that.

The first version of NFS I saw only used 12 of the 32 bytes
in the file handle, in three parts:
	* Four bytes of major/minor device number
	* Four bytes of inode number
	* Four bytes of version number [how many times this
		particular inode has been reused]
As it turns out, the high order three bytes of the version number
would always be zero, since only one byte in the inode was used
to keep the version number.

So to build a file handle, one could try using 2 for the inode
number (the root inode), 1 for the version number (since the
root inode never gets deleted), and that leaves the major/minor
device number.  If you have any idea what sort of machine you're
attacking, that's easy to guess.  For example, on my Sun system,
/dev/sd0a is 7,0.  So a valid file handle for the root directory
of the root file system would be:
	0x00000700 0x00000002 0x00000001
followed by another 20 bytes of zeroes!

And as has been discussed here, once you have a valid file handle,
you're home free.

I certainly *hope* there's no one out there still running such a
brain-damaged version of NFS, but since the handle is by definition
"opaque", it could well be that some vendors haven't improved this
original mechanism.

--Jeremy Epstein
Cordant, Inc.
jepsteincordant.com