[2169] in SIPB_Linux_Development
Re: Kerberized NFS docs
daemon@ATHENA.MIT.EDU (mhpower@MIT.EDU)
Wed Sep 23 22:45:07 1998
From: mhpower@MIT.EDU
Date: Wed, 23 Sep 1998 22:44:55 -0400
To: nygren@MIT.EDU
Cc: linux-dev@MIT.EDU
In-Reply-To: "[2166] in SIPB_Linux_Development"
> http://web.mit.edu/linux/www/NFS/
This refers people to an rpm with an nfs-service implementation based
on an nfs-server-2.2beta16 version once distributed by RedHat
(probably some time in 1996 or 1997). RedHat nfs-server-2.2beta rpm's
released prior to August 27 of this year have the mount-logging
buffer overflow described at http://www.mit.edu:8008/menelaus/bt/7795,
which mentions "the bug can be exploited even if your client is not
listed in the exports file".
I believe we don't want users downgrading to this old version of the
nfs-service code, even if they really want Kerberos. Outsiders
regularly scan all of MITnet looking for nfs servers, and are
potentially capable of breaking in to all of the Linux ones with this
bug. It'd probably be best if there weren't a way to get to the old
version's rpm starting from http://web.mit.edu/linux/www/.
The other problem with this Kerberized nfs implementation is that I
think it's possible for an attacker to obtain access via nfs with any
uid on the server, including uid 0, by forging packets of the type
that would ordinarily constitute the mountd-to-nfsd communication.
This makes the server less secure than with a standard default nfs
server configuration, in the sense that the standard defaults don't
allow any clients to have uid 0 access to the server. There's a
workaround for this problem available with the IP firewalling code,
but presumably many users won't have that in place.
The other Kerberized nfs implementations used in the Athena
environment don't use mountd-to-nfsd communication to alter what
server uid's will be used for filesystem access; instead, mountd makes
a system call that's restricted to callers with uid 0. Thus, there's
no way for packet forging to be useful in getting access to a uid
that hasn't already been made available through the intended
mechanisms (i.e., either authentication for a principal listed in the
credentials file, or actually having root access on the server).
Matt
