Reported to the Red Hat Security Response Team via secalert: "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." Acknowledgements: 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 <ikent> - 5.0.1-0.rc2.7 - make default installed master map for /net use "-hosts" instead of auto.net. 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 user) 3. the attacker removes ~/.ssh, and replaces it with a symlink to /net/dos.tld/export 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.
removing embargo
This issue was addressed in: Red Hat Enterprise Linux: http://rhn.redhat.com/errata/RHSA-2007-1128.html http://rhn.redhat.com/errata/RHSA-2007-1129.html Fedora: https://admin.fedoraproject.org/updates/F7/FEDORA-2007-4469 https://admin.fedoraproject.org/updates/F8/FEDORA-2007-4532