Node:exposed vulnerabilities, Next:implementation vulnerabilities, Previous:new vulnerabilities, Up:Security
The SFS read-write server software requires each SFS server to run an NFS server. Running an NFS server at all can constitute a security hole. In order to understand the full implications of running an SFS server, you must also understand NFS security.
NFS security relies on the secrecy of file handles. Each file on an
exported file system has associated with it an NFS file handle
(typically 24 to 32 bytes long). When mounting an NFS file system, the
mount
command on the client machine connects to a program
called mountd
on the server and asks for the file handle of
the root of the exported file system. mountd
enforces access
control by refusing to return this file handle to clients not authorized
to mount the file system.
Once a client has the file handle of a directory on the server, it sends NFS requests directly to the NFS server's kernel. The kernel performs no access control on the request (other than checking that the user the client claims to speak for has permission to perform the requested operation). The expectation is that all clients are trusted to speak for all users, and no machine can obtain a valid NFS file handle without being an authorized NFS client.
To prevent attackers from learning NFS file handles when using SFS, SFS encrypts all NFS file handles with a 20-byte key using the Blowfish encryption algorithm. Unfortunately, not all operating systems choose particularly good NFS file handles in the first place. Thus, attackers may be able to guess your file handles anyway. In general, NFS file handles contain the following 32-bit words:
In addition NFS file handles can contain the following words:
Many of these words can be guessed outright by attackers without their needing to interact with any piece of software on the NFS server. For instance, the file system ID is often just the device number on which the physical file system resides. The i-number of the root directory in a file system is always 2. The i-number and generation number of the root directory can also be used as the i-number and generation number of the "exported directory".
On some operating systems, then, the only hard thing for an attacker to guess is the 32-bit generation number of some directory on the system. Worse yet, the generation numbers are sometimes not chosen with a good random number generator.
To minimize the risks of running an NFS server, you might consider taking the following precautions:
fsirand
that
re-randomizes all generation numbers in a file system. Running
fsirand
may result in much better generation numbers than,
say, a factory install of an operating system.
localhost
for SFS, but read-only to any client on which an
attacker may have learned an NFS file handle, you may be able to protect
the integrity of your file system under attack. (Note, however, that
unless you filter forged packets at your firewall, the attacker can put
whatever source address he wants on an NFS UDP packet.) See the
mountd
or exports
manual page for more detail.
Note: under no circumstances should you make your file system
"read-only to the world," as this will let anyone find out NFS file
handles. You want the kernel to think of the file system as read-only
for the world, but mountd
to refuse to give out file handles
to anybody but localhost
.
mountd -n
.The mountd
command takes a flag -n
meaning "allow
mount requests from unprivileged ports." Do not ever run use
this flag. Worse yet, some operating systems (notably HP-UX 9) always
exhibit this behavior regardless of whether they -n
flag has
been specified.
The -n
option to mountd
allows any user on an NFS
client to learn file handles and thus act as any other user. The
situation gets considerably worse when exporting file systems to
localhost
, however, as SFS requires. Then everybody on the
Internet can learn your NFS file handles. The reason is that the
portmap
command will forward mount requests and make them
appear to come from localhost
.
portmap
forwardingIn order to support broadcast RPCs, the portmap
program will
relay RPC requests to the machine it is running on, making them appear
to come from localhost
. That can have disastrous consequences in
conjunction with mountd -n
as described previously. It can also
be used to work around "read-mostly" export options by forwarding NFS
requests to the kernel from localhost
.
Operating systems are starting to ship with portmap
programs
that refuse to forward certain RPC calls including mount and NFS
requests. Wietse Venema has also written a portmap
replacement that has these properties, available from
ftp://ftp.porcupine.org/pub/security/index.html. It is also a
good idea to filter TCP and UDP ports 111 (portmap
) at your
firewall, if you have one.
Many NFS implementations have bugs. Many of those bugs rarely surface
when clients and servers with similar implementation talk to each other.
Examples of bugs we've found include servers crashing when the receive a
write request for an odd number of bytes, clients crashing when they
receive the error NFS3ERR_JUKEBOX
, and clients using
uninitialized memory when the server returns a lookup3resok
data
structure with obj_attributes
having attributes_follow
set
to false.
SFS allows potentially untrusted users to formulate NFS requests (though of course SFS requires file handles to decrypt correctly and stamps the request with the appropriate Unix uid/gid credentials). This may let bad users crash your server's kernel (or worse). Similarly, bad servers may be able to crash a client.
As a precaution, you may want to be careful about exporting any portion
of a file system to anonymous users with the R
or W
options to Export
(see export). When analyzing your NFS code
for security, you should know that even anonymous users can make the
following NFS RPC's on a local-directory in your
sfsrwsd_config
file: NFSPROC3_GETATTR
,
NFSPROC3_ACCESS
, NFSPROC3_FSINFO
, and
NFSPROC3_PATHCONF
.
On the client side, a bad, non-root user in collusion with a bad file server can possibly crash or deadlock the machine. Many NFS client implementations have inadequate locking that could lead to race conditions. Other implementations make assumptions about the hierarchical nature of a file system served by the server. By violating these assumptions (for example having two directories on a server each contain the other), a user may be able to deadlock the client and create unkillable processes.
logger
buffer overrunSFS pipes log messages through the logger
program to get them
into the system log. SFS can generate arbitrarily long lines. If your
logger
does something stupid like call gets
, it may
suffer a buffer overrun. We assume no one does this, but feel the point
is worth mentioning, since not all logger programs come with source.
To avoid using logger
, you can run sfscd
and
sfssd
with the -d
flag and redirect standard error
wherever you wish manually.