Reported to the Red Hat Security Response Team via firstname.lastname@example.org:
"A stock install of RHEL5 and Fedora 8 (and possibly earlier versions) have
/net managed by autofs (look at /etc/auto.master).
Unfortunately, the "nosuid" mount option is not specified, meaning that any
system auto-mounted under /net may have arbitrary suid root binaries.
How to exploit this vulnerability:
An attacker can set up an NFS server on a remote host, and connect to the
vulnerable system with an unprivileged user account.
>From here, the attacker can change directory to /net/remote.host.tld/export
on the vulnerable system, and execute arbitrary "setuid root"
binaries that they have placed on their nfs server."
Red Hat would like to thank Josh Lange for reporting this issue.
Verified the above on RHEL5; an unprivileged user can mount a filesystem via nfs
and gain privileges via setuid files. This is the change that moved from
auto.net (which used nosuid option) to -hosts (which doesn't use nosuid option)
* Wed Sep 27 2006 Ian Kent <email@example.com> - 5.0.1-0.rc2.7
- make default installed master map for /net use "-hosts" instead
So this issue affects RHEL5 (and probably Fedora 7/8/devel)
(Red Hat would like to thank Josh Lange for reporting this issue)
Contacting vendor-sec to see if anyone else is affected.
Though a lot less critical, I can also think of numerous DoS attacks that can
also be played out on the /net autofs mountpoint. I don't know how critical the
/net feature is to RedHat, but mounting arbitrary remote filesystems (especially
without "-soft") can be very troublesome. As a system administrator, I can see
very handy uses for /net, but system stability concerns me a lot more.
Here is a scenario where ssh can be put into a state where it will no longer
accepts new connections:
1. an attacker starts an nfs server at dos.tld with "/export" exported
2. the attacker logs into a system that uses autofs to manage /net (as a normal
3. the attacker removes ~/.ssh, and replaces it with a symlink to
4. the attacker changes directory to ~/.ssh
5. the attacker stops his nfs server, and then types "ls"
6. the attacker then closes his ssh session with ~.
SSH will be blocked trying to read data off of the attacker's nfs share
The same issue is likely to affect a huge number of services, like apache (with
a rogue user using their personal webpage, or a remote attacker exploiting php
code injection in poorly written php code).
Neither issue affects us (the Cal Poly Computer Science Department) directly,
because we use custom autofs scripts, which are only willing to mount paths that
we have approved. But, we are currently using Fedora and CentOS on several of
our systems, want to ensure that the platform is as stable/secure as it can be.
This issue was addressed in:
Red Hat Enterprise Linux: