[872] in linux-security and linux-alert archive
Re: [linux-security] A secure (?) nfs-server ?
daemon@ATHENA.MIT.EDU (Brian Mitchell)
Mon Jul 1 14:44:13 1996
Date: Sun, 30 Jun 1996 06:03:53 -0400 (EDT)
From: Brian Mitchell <brian@saturn.net>
To: aleipold@clark.net
cc: Gerald Anderson <gander@defiant.vte.com>,
Angel Rat <sandman@chiara.dei.unipd.it>,
linux-security@tarsier.cv.nrao.edu
In-Reply-To: <Pine.SOL.3.93.960628202150.27862D-100000@clark.net>
On Fri, 28 Jun 1996 aleipold@clark.net wrote:
> I recently ran into a new hole regarding NFS.
> Insted of exploiting it, I figured I would tell you about it.
>
>
> I have run into a new security hole that is extremely powerful. This
> trick is not all that complicated. I really should have thought of it
> before. Some of you, I'm sure, with Linux boxes, may have noticed that at
> times when you run IRC you don't always get your account as your "whois".
> For example, let us say that you SLIP up and your account is john@fruit.net,
> but your box name is: root@Ihack.com, sometimes your identd returns:
> root@fruit.net. This, I should have realized could be a seriously nice
> hack. However it turned out that your REAL inetd name was returned when
it should always retern john, when it returns root it obviously is not
doing a ident check, and you probably have a ~ next to your username.
There is no way for you to forward 113 on the shell machine to 113 on
your machine without having root on the shell machine.
> telneting, mounting, etc. So how to break that? Slirp. Slirp redirects
> TCP ports from one to another. For example if you are john@fruit.net and
> you run slirp with the command "redir tcp 31337 to 23" when someone
> telnets to fruit.net 31337 it will connect them to your box. Now here is
> the catch. If you are john@fruit.net, logged in as root on your box, the
> identd returns root@fruit.net -- bingo. However, for most BSD 4.3 compatible
> systems in.identd should be commented out in /etc/inetd.conf (On your system)
But on Linux, this is not so. identd is included and enabled in most
distribution, not that it has anything whatsoever to do with nfs.
>
>
> Now let us say that on the fruit.net domain there are other servers
> that are often NFS mounted by fruit.net. So at boot up fruit.net mounts via NFS
> jonx.fruit.net. In this case that means that root@fruit.net can mount
> jonx.fruit.net READ/WRITE. Now here is the part that becomes a little
> complicated. There are several ways that you can set up your exports file.
>
> / (rw) [stupid]
> / (rw,insecure) [really stupid]
> / IPADDRESS(rw) [common way]
> / IPADDRESS(rw,root_squash) [secure way]
No, not running nfs at all is the secure way.
>
> Let us say that fruit.net's ip address is 192.144.12.2 Chances are
> jonx.fruit.net has it set up as: "/ 192.144.12.2(rw)". If so your in for
> fun. Here is how to go about. Get slirp compile it on your account on
> fruit.net then go to your system, login as root and type:
> mount jonx.fruit.net:/ /mnt/
>
> It should mount. This is because when it checks who is attempting to NFS
> mount it, it looks up your name (root), and your ip which is, thanks to
> slirp, not your real SLIP ip, but 192.144.12.2 or whatever your host is.
> However, the reason that this works is because nfsd is inherently insecure.
> It assumes that only the trusted 'root' is mounting the remote file system.
> Also, it does not check to see that the mount request originates from a
> reserved port (<1023). Slirp usually binds to ports between 30000-60000 for
> TCP/UDP connections.
It will work, but you are confused about identd. Identd does not look up
udp connections - indeed, it could not; UDP does not have connections. It
is a connectionless protocol. In nfs, you tell the server what uid you
are (sure, you can trust me mr server, I really am root - honest!), which
in and of itself is the main problem.
[description of 2 ways this can be abused clipped]
> Slirp can be used as a hack to use a Unix workstation/server to impersonate
> a trusted host and well as it's resources.
Indeed, but it is not necessary to use slirp to do any of this.
>
> A protection against this would simply to require all important network
> connections for UDP and TCP to orginate from a priviliged port. That would
> mean that root on the real system would have to run the service. Since only
> root can bind to ports below 1023.
I'm no NFS expert, but I was under the impression that this is done by
many nfs daemons already. Perhaps not... rsh and rlogin both require
connections to originate from a privledged port (as well they should,
otherwise host based authentication would be even less secure than it is
already [is this possible?]).
>
> Well you get the idea of flaws with Slirp combined with ident.
No, you get the idea of NFS flaws. The exact same thing could be done
right from the shell account by issuing mount requests (there is code for
sunos floating around that does this very thing). Again, this has
absolutely nothing to do with identd.
Brian Mitchell brian@saturn.net
Unix Security / Perl / WWW / CGI http://www.saturn.net/~brian
"I never give them hell. I just tell the truth and they think it's hell"
- H. Truman
