COMMAND
4.4BSD NFS File Handles
SYSTEMS AFFECTED
4.4BSDLite2 appears vulnerable based on source inspection only.
BSD/OS 2.0, 2.1, 3.0
FreeBSD 2.1.5, 2.1.6, 2.1.7
NetBSD 1.2 appears vulnerable based on source inspection only.
OpenBSD 2.0 is vulnerable.
OpenBSD-current obtained on 14 February 1997 or earlier is
vulnerable.
PROBLEM
Following information is Secure Networks Inc. copyright and this
text is part of their security advisory (March 7, 1997).
There is a serious vulnerability in 4.4BSD and derivatives which
allows unprivileged users to obtain valid NFS file handles. A
NFS file handle will permit a user to, at the least, obtain
access as any non-root user to the filesystem, and possibly
obtain root privileges.
The problem occurs due to the fact that unprivileged users are
able to obtain all information required to generate NFS file
handles.
In addition to returning traditional information, such as the
creation time, size, inode number and last modification time, the
4.4BSD stat(2) system call and related functions return a field
called st_gen. The st_gen field is a 4 byte value which is
different for each item on the filesystem. The st_gen value is
used as a generation number to make NFS file handles difficult to
guess. Unfortunately, because all information used to generate a
file handle is availible to users, a user can generate file
handles identical to those given to NFS client hosts accessing
file systems on the local server.
Because a file handle is all that is needed to mount a
filesystem, a user can then mount any exported filesystems,
performing arbitrary filesystem operations as any non-root user,
assuming they are on a host in the server's export list. Such
access will commonly result in the user obtaining root privileges.
The incorrect code in the vn_stat() function, called by stat(2)
reads:
...
sb->st_gen = vap->va_gen;
sb->st_blocks = vap->va_bytes / S_BLKSIZE;
return (0);
}
It should be noted that in the above source code, all information
from the generation number is pulled out and given to the user.
A correct implementation will only permit root users to access
this number, as shown in the following example source code:
...
sb->st_flags = vap->va_flags;
if (suser(p->p_ucred, &p->p_acflag)) {
sb->st_gen = 0;
} else {
sb->st_gen = vap->va_gen;
}
sb->st_blocks = vap->va_bytes / S_BLKSIZE;
return (0);
}
This will cause the st_gen field of the stat structure returned to
unprivileged users to be zero, thus preventing ordinary users from
determining file handles simply from the information returned by
stat(2). Individuals with shell access to a NFS server or client
can obtain access to the NFS server as any non-root user. This
will usually lead to root compromise.
If you have any questions about SNI advisory, feel free to mail
author at davids@secnet.com. Theo Deraadt initially alerted to
this problem which was discovered by David Mazieres.
SOLUTION
Note that OpenBSD-current obtained later than February 14 is not
vulnerable.
If you are running a NFS server on your 4.4BSD system, or using a
4.4BSD system as a NFS client, we suggest modifying your kernel
so that stat(2), and lstat(2) do not provide st_gen to
unprivileged users. You should also modify any system calls
which return the same information as the above functions, but
which exist solely for backwards compatibility with 4.3BSD.
Finally, the generation numbers assigned to new inodes should be
nonguessable. Vendors are strongly urged to provide a utility to
enable administrators to re-randomize the generation numbers when
they suspect that file handles have been comprimised.
A program to randomize generation numbers on 4.4BSD derived file
systems can be obtained at:
ftp://ftp.secnet.com/pub/tools/bsd-fsirand/fsirand.tar.gz.
WARNING: The above fsirand program has been tested on various
4.4BSD derived operating systems and has performed without
problems. With this in mind, there is absolutely no guarantee
that this program will work correctly on your file systems, and
users should back up all data prior to randomizing generation
numbers. The author assumes no liability. To initially verify
that fsirand will work correctly, a user may want to create a
file system on a floppy drive and test the fsirand program on
that file system.
BSD/OS: Contact BSDi for a fix. A fix will be availible
shortly after the release of this advisory. BSDI patches can
be obtained by ftping to ftp://ftp.bsdi.com/pub/patches or by
mailing patches@bsdi.com. The fsirand program has been
tested on BSD/OS 2.1 and has functioned without any problems.
FreeBSD and NetBSD: Back up your system. Then apply the
included patch, then recompile your kernel and reboot in
single user mode. At this point the fsirand program should
be run on all exported file systems. Once complete, reboot
to multi-user mode. It would be a good idea to run fsirand
on all file systems, in the event that some may be exported
in the future.
OpenBSD: Back up your system. Then use anoncvs to upgrade
your system to OpenBSD-current, recompile your kernel, and
reboot in single user mode. Run the fsirand program which is
part of OpenBSD in order to randomize generation numbers for
pre-existing filesystems. Finally reboot to multi-user mode.
The following diffs are to the 4.4BSDLite2 vfs_vnops.c, and
prevent users from using stat(2) and related system calls for
obtaining file handle generation numbers.
*** vfs_vnops.c Thu Mar 6 21:37:16 1997
--- vfs_vnops.c.orig Thu Mar 6 21:34:53 1997
***************
*** 344,350 ****
sb->st_ctimespec = vap->va_ctime;
sb->st_blksize = vap->va_blocksize;
sb->st_flags = vap->va_flags;
! sb->st_gen = vap->va_gen;
sb->st_blocks = vap->va_bytes / S_BLKSIZE;
return (0);
}
--- 344,354 ----
sb->st_ctimespec = vap->va_ctime;
sb->st_blksize = vap->va_blocksize;
sb->st_flags = vap->va_flags;
! if (suser (p->u_cred, &p->p_acflag)) {
! sb->st_gen = 0;
! } else {
! sb->st_gen = vap->va_gen;
! }
sb->st_blocks = vap->va_bytes / S_BLKSIZE;
return (0);
}