[865] in linux-security and linux-alert archive
Re: [linux-security] A secure (?) nfs-server ?
daemon@ATHENA.MIT.EDU (aleipold@clark.net)
Sat Jun 29 16:03:42 1996
From: aleipold@clark.net
Date: Fri, 28 Jun 1996 20:23:58 -0400 (EDT)
To: Gerald Anderson <gander@defiant.vte.com>
cc: Angel Rat <sandman@chiara.dei.unipd.it>,
linux-security@tarsier.cv.nrao.edu
In-Reply-To: <199606280139.UAA00987@defiant.vte.com>
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
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)
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]
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.
Now you can access the shadow file(usefull for cracking).
This nfs mount can be used to create a root-suid shell.
All you need to do is create a suid shell (bash).
Simply run : "cp /mnt/bin/bash /mnt/rootacct" (or wherever bash is)
then from your box do: "chown root.root /mnt/rootacct"
then "chmod 4755 /mnt/rootacct"
Congrats, you now have a setuid shell that when run by a normal user
gives you euid(0).
Slirp can be used as a hack to use a Unix workstation/server to impersonate
a trusted host and well as it's resources.
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.
Well you get the idea of flaws with Slirp combined with ident.
--Later fooz.
Mknod (Sphear Inc.) Signal (Eraser Tech.)
