Bug 917977 (CVE-2014-8169)

Created attachment 623333 [details]
Patch for CVE-2014-8169

Date: Fri, 13 Feb 2015 17:23:47 +0100
From: Vasyl Kaigorodov <vkaigoro@redhat.com>

We've got notified about below issue in autofs by Georgia Institute
of Technology, parts of their report below:
...
Between 1:autofs-5.0.5-89.el6_5.2.x86_64 (RHEL6.5) and
1:autofs-5.0.5-109.el6.x86_64 (RHEL6.6), a number of
variables were added to the environment in which executables
defined in "program:/path/to/executable" based autofs maps
are run.

USER and HOME are among those variables.  The values are set
to the unprivileged user triggering the automount request
rather than the user under which the specified program
is executing (root).

Depending on the program specified for a mapping, this can
be the origin of a privilege escalation.  In our case, it
was found that upon updating to RHEL6.6, a map written in
python and running as root courtesy of a program: entry in
auto.master, was all of a sudden automatically attempting to
load modules from the user's home directory
(~/.local/lib/pythonX.Y/site-packages) due to the added HOME
environment.  The hashbang on this map program had been only
(#!/bin/python), not specifying the options "-s" or "-S"
necessary to avoid using the user's site path.  The lack of
inclusion of -s/-S is an issue on our part (now fixed), but
I doubt we are the only one.

Addition of unscoped unprivileged user environment values to
the root program execution environment does not appear to be
documented anywhere.  autofs(5) mentions variable
substitution is available for the location field, but
nothing indicates executable maps now also get them by
default.  RHEL6.6 technical notes also do not mention the
modification.

The default selinux confinement of autofs prevents this
escalation by prohibiting automount_t from accessing a
user's home directory.  The resultant AVC is what lead us to
the issue.

This is only a problem if someone has configured auto.master
with a program:/some/executable map where /some/executable
utilizes HOME in an insecure fashion.  Unfortunately that
happens by default if /some/executable is a python script,
or any other interpreted language which sets its load path
based on HOME.  Use of program:/some/executable maps are
relatively uncommon, so the overall impact of this is likely
small.

Presumably the variables were added to the execution
environment for a reason.  Would it be acceptable to prefix
them with something?  AUTOMOUNT_USERHOME seems far less
likely to inadvertently enable a search path based privilege
escalation, especially for various interpreted languages,
than an autofs started program running as root with the
environment of HOME=/home/malicioususer.  Either way, the
inclusion of the variables should at least be noted in the
man page.
...

Privilege escalation is possible via the below vector:

...
Local privilege escalation.  In our case, we have over 100,000
accounts and auto.master entries like:
    /nethome        program:/etc/auto.nethome
    /projects       program:/etc/auto.projects

(where account $HOME is set to /nethome/$uid)

At any given time, at least one of those many accounts is
probably not solely controlled by the intended user or it
is a student with a legitimate account who wants root.

They just drop a file in ~/.local/lib/pythonX.Y/site-packages
and trigger automount to load it as root by simply running
"ls /projects/doesntexist".

Worse, since it is a network mounted home directory, this can
be triggered on systems that the user does not even have
access to log into.  Under certain configurations, sshd will
trigger automount for the home directory in order to check
authorized_keys or k5* before the user completes
authentication.  Since the user can add files to ~/ from a
legitimate host, they could compromise a remote host (which
would mount their directory if they logged in) simply by
trying and failing an ssh authentication.
...

The proposed patches (attached) workaround this by setting variables
with special prefix, e.g. AUTOFS_HOME, AUTOFS_USER, ... That will
prevent collision, while leaving possibility for programs to have
access to the values.
By default a prefix of AUTOFS_ (that isn't configurable) will be used
for these environment variables, a configuration option will be
provided to allow the prefix to not be added.

We would like to hear opinions from other vendors regarding this
issue, and if the suggested approach of fixing this is fine.
We'd also like to coordinate disclosure date.