Re: Blind IP Spoofing Attacks.

[jmason () iona ie (Justin Mason)]

> They mention that NFS and Sun RPC in general are
> vulnerable to the sequence number attack.  It is true that
> nfs and other rpc's do rely on IP address for authentication
> but I dont see how they are vulnerable to an attack.  You
> need to see the reply in order to get a filehandle in order
> to do anything with nfs.

If you can guess the filehandle, you don't need the reply
packet.

NFS' filehandles aren't really unguessable on some machines;
for example, an unpatched SunOS 4.1.2 machine doesn't really
make it difficult enough.

All the same, I think many of the NFS attacks rely on being able to
guess a valid directory fh, lookup .., cd .. until it hits the root --
not being able to read the reply packets would make it impossible to
read the values for ..'s fh.

Also, using rsh to do 'echo "+ +" > /.rhosts' would be a hell of
a lot easier... ;)

Here's some relevant stuff I have saved from bugtraq; you might also
want to read the source for nfsbug for more details.

--j.

%Date:         Tue, 19 Apr 1994 17:21:12 +0200 (METDST)
%To:           bugtraq () crimelab com
%From:         Stefano Taino <taino () dsi unimi it>
%Subject:      Re: More on NFS hacking

As near as I can tell, this is Sun's definition of the "opaque" file handle:

        long device;    /* device of FS on server. */
        long fs_type;   /* file system type of FS on server. */

        long fsid;      /* fsid of file being specified. */
        long fid;       /* fileid  " " " " */
        long gen;       /* generation " " " " */

        long exp_fsid;  /* fsid of export point on server. */
        long exp_fid;   /* fileid " " " " " */
        long exp_gen;   /* fileid " " " " " */

For the file handle of an export point: 

        fsid == exp_fsid && fid == exp_fid && gen == exp_gen

if the export point happens to be at the root of a UNIX file system,
then both fid and exp_fid will be 2, since UNIX traditionally uses 2
for the root of its file systems.  But if a directory below the root of
a file system is exported, then exp_fid will contain whatever value
that is.

Here are some sample file handles from a Sun server running SunOS
4.1.1.  With "/home" (root of a file system) as the export point, the
fh of the export point is:

        1799 1 655360 2 1155997163 655360 2 1155997163

With "/home/eng" as the export point, the fh of the export point was:

        1799 1 655360 26276 1648502143 655360 26276 1648502143

Notice that there isn't a 2 anywhere in the file handle.  When I
mounted "/home/eng" when the export point was "/home", the fh of the
mount point was:

        1799 1 655360 2 1155997163 655360 2 1155997163

Notice that the {fsid,fid,gen} triple here matches that triple from the
second case, while the {exp_fsid,exp_fid,exp_gen} triple matches that
triple from the first case.  This is because the first triple
represents that actual file the fh is fore, and the second triple
represents the export point of that fh.


-- Stefano.

%From: jsz () ramon bgu ac il (jsz)
%Subject: Re: RPC protocol problem?
%Date: Thu, 25 Aug 94 3:46:00 IDT
%Cc: bugtraq () crimelab com

> "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.