Bugtraq mailing list archives
More on NFS hacking
From: jepstein () cordant com (Jeremy Epstein -C2 PROJECT)
Date: 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. jepstein () cordant com
Current thread:
- More on NFS hacking Jeremy Epstein -C2 PROJECT (Apr 18)
- <Possible follow-ups>
- Re: More on NFS hacking Stefano Taino (Apr 19)