Bug 410031 (CVE-2007-5964) - CVE-2007-5964 autofs defaults don't restrict suid in /net
Summary: CVE-2007-5964 autofs defaults don't restrict suid in /net
Alias: CVE-2007-5964
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 409701 410041 410051 412621 412631 421351 421361 421371
TreeView+ depends on / blocked
Reported: 2007-12-04 10:13 UTC by Mark J. Cox
Modified: 2021-02-25 17:38 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-01-11 16:59:44 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2007:1128 0 normal SHIPPED_LIVE Important: autofs security update 2007-12-12 12:36:58 UTC
Red Hat Product Errata RHSA-2007:1129 0 normal SHIPPED_LIVE Important: autofs5 security update 2007-12-12 12:41:09 UTC

Description Mark J. Cox 2007-12-04 10:13:27 UTC
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."


Red Hat would like to thank Josh Lange for reporting this issue.

Comment 1 Mark J. Cox 2007-12-04 10:16:52 UTC
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)

Comment 8 Mark J. Cox 2007-12-05 06:36:24 UTC
(Red Hat would like to thank Josh Lange for reporting this issue)

Contacting vendor-sec to see if anyone else is affected.

Comment 9 Josh Lange 2007-12-05 07:16:02 UTC
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.

Comment 18 Mark J. Cox 2007-12-12 12:26:43 UTC
removing embargo

Note You need to log in before you can comment on or make changes to this bug.