Bug 410031 - (CVE-2007-5964) CVE-2007-5964 autofs defaults don't restrict suid in /net
CVE-2007-5964 autofs defaults don't restrict suid in /net
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
high Severity high
: ---
: ---
Assigned To: Red Hat Product Security
reported=20071204,impact=important,pu...
: Security
Depends On: 409701 410041 410051 412621 412631 421351 421361 421371
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-04 05:13 EST by Mark J. Cox (Product Security)
Modified: 2010-02-23 23:46 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-11 11:59:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Mark J. Cox (Product Security) 2007-12-04 05:13:27 EST
Reported to the Red Hat Security Response Team via secalert@redhat.com:

"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.
Comment 1 Mark J. Cox (Product Security) 2007-12-04 05:16:52 EST
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@redhat.com> - 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 (Product Security) 2007-12-05 01:36:24 EST
(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 02:16:02 EST
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.
Comment 18 Mark J. Cox (Product Security) 2007-12-12 07:26:43 EST
removing embargo

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