Multiple security issues in Apport

[Marc Deslauriers]

We have received the following advisory:

Security vulnerability report: multiple vulnerabilies in Apport / Ubuntu
========================================================================

OVERVIEW
--------

Author: Sander Bos
Author's e-mail address: sbos _at_ sbosnet _dot_ nl
Author's web site: www.sbosnet.nl
CVE numbers: requested
Date: 2017-10-23
Version: 2

SUMMARY
-------

Several security vulnerabilities were discovered by Sander Bos in the
"Apport" crash handler program [1] affecting all currently supported
releases of Ubuntu (12.04 LTS (ESM), 14.04 LTS, 16.04 LTS, 17.04, 17.10)
and, likely, other distributions and Ubuntu derivatives using Apport
as well.

Exploitation types are privilege escalation (root exploitation), full
disk DoS, and Linux container escaping.

DESCRIPTION, WITH PROPOSED FIXES / WORKAROUNDS
----------------------------------------------

Issue 1 (CVE-2017-14177): Incomplete fix for CVE-2015-1324
-----------------------------------------

Exploitation types: privilege escalation, full disk DoS.

Ubuntu releases affected: 12.04 LTS (ESM), 14.04 LTS, 16.04 LTS, 17.04, 17.10
(i.e., all currently supported releases).
Note: default OS installations might need an extra package installed,
or a system configuration setting changed, to be exploitable.

Description:

The Apport issue I reported in 2015 (CVE-2015-1324) [2], leading to
privilege escalation, was not fixed properly. The initial issue and
vulnerability still apply, although to a lesser extent.

Since the introduction of the fix [3] Apport detects setuid, unreadable,
and other types of tainted / protected binaries / processes by
comparing the real UID and real GID of the crashed process, read from
/proc/<pid>/status and which Apport first sets its own UID and GID to,
with the UID and GID file owner information of /proc/<pid>/stat.

For non tainted processes, the file owner information of /proc/<pid>/stat
is the UID and GID of the user that started the process. For tainted
processes, the file owner information is 0.

If the comparison does not match, Apport assumes the process to be a
tainted process, and disables writing a core dump file. This on itself
is correct.

However, if the comparison _does_ match, it is not always correct to
assume that the process is _not_ a tainted process (and, consequently,
write a core dump file). For example, some setuid programs run by users
receive real UID 0 and real GID 0. Also, some setuid processes started
by root (partially) drop privileges at some point (after which users
could crash them), for example after forking, but retain real UID 0 and
real GID 0.

In such cases, Apport writes a core dump file (as root) while in fact
it should not do so. This brings back the problem of CVE-2015-1324.

It should also be noted that, for the same reason, Apport "dropping privileges"
to the real UID and real GID read from /proc/<pid>/status is at times
incorrect and, thus, unsafe as well.

Proposed fix:

The proper fix is to really _never_ write a core dump file for processes
where suid_dumpable=2 got effectuated. This was probably what was
intended with the fix for CVE-2015-1324, but the check that was created
does not catch all cases of tainted processes. A better approach would
be to let Apport read out "%d" from core(5) through "kernel.core_pattern"
and if it returns "2", not write a core dump file. Note however that
"%d" is only present since kernel version 3.7, and would thus not work
on Ubuntu 12.04 LTS systems running a 3.2 "GA" (General Availability)
kernel from earlier Ubuntu 12.04.x LTS releases (as opposed to such
systems running a 3.13 "HWE" (Hardware Enablement Stack) kernel from
later Ubuntu 12.04.x LTS releases).

Issue 2 (CVE-2017-14179): Apport lacking container / PID namespace support
and
Issue 3 (CVE-2017-14180): Apport broken container / PID namespace support
---------------------------------------------------------

Exploitation types: container escape, privilege escalation, full disk DoS.

Ubuntu releases affected: 12.04 LTS (ESM), 16.04 LTS, 17.04, 17.10.
Note: exploitable on default OS installations.

Description:

Issue 2 (CVE-2017-14179):
Ubuntu 12.04 LTS: Apport does not recognize ("support")
PID namespaces / containers.

Issue 3 (CVE-2017-14180):
Ubuntu 16.04 LTS, Ubuntu 17.04, and Ubuntu 17.10: Apport supports
containers, but checks if a crashed program originated in a container
only by checking for a mismatch of the global PID and the local PID of a
crashed process. This check will in fact be true in case of a process
that originated in a container. However, the check does not suffice
because a second, nested, PID namespace can exist in the container
(without itself being part of another "full" container). In that case
Apport (or, actually, a second Apport called by the host OS Apport,
and running in the container) will incorrectly take information from
the container /proc directory while in fact that /proc does not belong
to the PID namespace from which the crashed process originated.

(Ubuntu 14.04 LTS, the other supported Ubuntu release, does detect
containers but not "support" them: it exits in case of a global / local
PID mismatch. Apport's container support was disabled in April 2015
due to security vulnerabilities and re-implemented in February 2016,
but the new container support implementation was not added to
Ubuntu 14.04 LTS, probably because it uses sytemd features and
Ubuntu 14.04 LTS does not run systemd. Thus, Ubuntu 14.04 LTS is not
vulnerable, although that is more or less by coincedence.)

Apport misreading /proc for PID namespaces processes breaks Apport's
functionality for applications that use "CLONE_NEWPID" (see the clone(2)
and unshare(2) man pages), because /proc<pid>/ will either belong to
a different (global) process with the same global PID as the local PID
of the crashed proces, or it will not exist in case no global process
with that PID exists. This broken functionality is a bug on itself but,
worse, introduces a security vulnerability.

Simple demonstrational PoC:

To demonstrate the above, the following C program could be run as a
non-root user on for example an Ubuntu 17.10 (LXC) system container
(called "container OS" in the rest of this report) on an Ubuntu 17.04
host OS:

---
#define _GNU_SOURCE
#include <sched.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/resource.h>
#include <sys/time.h>

int main(void) {
   int pid;
   struct rlimit corelimit;

   corelimit.rlim_cur = RLIM_INFINITY;
   corelimit.rlim_max = RLIM_INFINITY;
   setrlimit(RLIMIT_CORE, &corelimit);

   unshare(CLONE_NEWUSER|CLONE_NEWPID);

   chdir("/tmp/");

   pid = fork();
   if (pid == 0) {
      abort();
   }
}
---

Thus, there are three layers: host OS -> container OS -> PID namespace.
The forked process in the program above will have PID 1 within the PID
namespace, i.e., within the third layer.

Running this program (in the container OS) will trigger Apport in the
host OS, which will forward the crash to the Apport of the container OS.
This second Apport instance will then actually handle the crash. It will
use PID 1 for this, since that's the PID that Apport from the host OS
has told it to use: the local PID of the crashed process.

This PID 1 is the local PID 1 from the PID namespace, but Apport from the
container OS reads from /proc/1/ from the container OS. This directory
actually belongs to PID 1 within the container OS, _not_ PID 1 from
within the PID namespace.

Effectively, the Apport in the container will create
a ".crash" crash report file in /var/crash/, for example
/var/crash/_lib_systemd_systemd.0.crash or /var/crash/_sbin_init.0.crash,
with UID root and GID root as file owner (although Apport may optionally
change the GID of the crash report file later on). Apport will also
create the file "/core", with UID root and GID root as file owner as well.

The files will contain /proc information belonging to (coming from),
and for the crash report file the path name of, the _global_ PID 1
within the container OS. Also, the CWD of that global PID 1 is taken
as the directory to write the core dump file in, not the CWD of the
crashed program (which is set to /tmp/ to demonstrate that). The core
dump contents in the crash report file and the contents of the "/core"
core dump file _are_ in fact coming from the crashed program, which is
correct, although exactly this can be used for further exploitation.

The above program also works on Ubuntu 12.04 LTS, when running as a host
OS (as opposed to running it as a container OS). The effect is similar,
but the cause of the effect is different (it's a different bug / code
issue): Apport in Ubuntu 12.04 LTS does not recognize at all that the
crashed process originated in a PID namespace / container, and it will
not see a global PID _and_ a local PID of the process, but only its
local PID 1 which it will then use (which is wrong, as that local PID
1 obviously is not the global PID 1).

For Ubuntu 12.04 LTS with a 3.2 "GA" (General Availability) kernel (from
earlier Ubuntu 12.04.x LTS releases), as opposed to such systems running
a 3.13 "HWE" (Hardware Enablement Stack) kernel (from later Ubuntu
12.04.x LTS releases), it should be noted that exploitation might be
more difficult, and perhaps not possible on default OS installations.
This is because user namespaces ("CLONE_NEWUSER", see the clone(2)
and unshare(2) man pages) is not available in kernel version 3.2, i.e.,
non-root users can not create PID namespaces ("CLONE_NEWPID" requires
"CLONE_NEWUSER"), although for example setuid programs from packages
installed by root could do this for them.

It should also be noted that exploitability of this vulnerability does
not only depend on what release of Ubuntu is running, but also if it is
running as the host OS, as a containers OS, or as both of them.

Below follows a, possibly incomplete but believed to be accurate,
overview of host OS / container OS combinations and what can be achieved
in exploitation in each combination. Full disk DoS scenarios are also
possible on either the host OS, the container OS, or both, but not
included here.

Host OS: 12.04 LTS
Container OS: not involved
Simple exploit: user on host OS creates "/core" on host OS
Privilege escalation exploit: user host OS -> root host OS

Host OS: 12.04 LTS
Container OS: any Linux distribution
Simple exploit: user in container OS creates "/core" on host OS
Privilege escalation exploit: user container OS -> root host OS
*** Note: effectively this means escaping a container, and is not limited to Ubuntu ***

Host OS: 16.04 LTS / 17.04 / 17.10
Container OS: 16.04 LTS / 17.04 / 17.10
Simple exploit: user on container OS creates "/core" on container OS
Privilege escalation exploit: user container OS -> root container OS

Note: escaping a container as mentioned in the
user container OS -> root host OS scenario above does not refer to a
general container escape technique using for example a bug in LXC, Linux
namespaces, or the fact that the kernel is shared between the container
and host OS; instead, it refers to a Apport specific, newly found, but
"indirect" method of escaping a container. The end effect is however
equal, thus it is mentioned as a way of escaping a container.

Note: the user container OS -> root container OS scenario could from
that point on lead to privilege escalation to root on the host OS, for
example by exploiting the fact that the container OS and the host OS
share the same kernel. Known, general techniques could be used for that.
This would require the container OS to be running in a "privileged"
container, i.e., a container created by and running as the root user on
the host OS, as opposed to be running in an "unprivileged" container,
i.e., a container created by but not running as root on the host OS,
or created by a non-root user on the host OS. This could for example
be the case when user namespaces are disabled or otherwise not available
on the host OS,

Proposed fix:

For Apport without container support (Ubuntu 12.04 LTS), a fix could be to
have Apport detect containers by comparing the global PID and the local
PID of a crashed process and if they don't match, exit (this is exactly
what is currently done in Ubuntu LTS 14.04). Note however that the "%P"
global PID template specifier from core(5) is only available and can
thus be only used in "kernel.core_pattern" since kernel version 3.12,
so this fix will be problematic to implement on Ubuntu 12.04 LTS systems
running a 3.2 "GA" (General Availability) kernel (from earlier Ubuntu
12.04.x LTS releases) (as opposed to Ubuntu 12.04 LTS systems running a
3.13 "HWE" (Hardware Enablement Stack) kernel from later Ubuntu 12.04.x
LTS releases).

For Apport with container support (Ubuntu 16.04 LTS, 17.04, 17.10),
a short term fix (workaround) could be to (again) disable container
support in Apport (this is what is currently done in Ubuntu 14.04 LTS).
A long term fix would probably be to have Apport do a proper container
check instead of only relying on PID number information. In any case,
it should be made sure not to read from the wrong /proc directory
(if that can be avoided with certainty at all, e.g., a "container" /
collection of namespaces might not have its own mount namespace or /proc,
in which case things might get difficult).

REFERENCES
----------

[1] <https://launchpad.net/apport>, <https://wiki.ubuntu.com/Apport>
[2] <https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1452239>
[3] <https://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2957>

REVISION HISTORY
----------------

2017-10-21: Version 1: initial version
2017-10-23: Version 2: fix minor errors, improve text, better explain
                       issue 1 (and explicitly mention that Apport
                       "drops privileges" unsafely), add references
                       section, add revision history section.

CREDITS
-------

Please credit "Sander Bos (www.sbosnet.nl)" (without the quotes) in all
documentation related to this issue including commit messages, releases,
patches, and security advisories; thank you.

EOF

[Stéphane Graber (stgraber)]

So I'm only going to cover the container piece and only for 16.04 and later as for everything else we should just do as good a job as we can to turn this off, but unfortunately due to what the kernel would provide in older kernels, I'm not sure that we can always determine that.

So the issue we have here is when a process has 3 PIDs:
 - ns0 pid (host machine)
 - ns1 pid (container where apport runs)
 - ns2 pid (some nested PIDNS which does not have a matching MNTNS + apport instance)

In such case, the kernel tells the host apport process about the ns0 and ns2 pids. Apport rightfully detects that the process is coming from a container, locates the apport socket and sends what it knows of the process across.

Apport in the container will then dump the wrong process as it wasn't provided the pid for the right level of pidns.

This also highlight another general issue with the way apport handles this today. We assume that ns0 pid != ns2 pid means we got a crash from a container. But it would actually be possible to create a clash there too, this may be very tricky to hit, but you could in theory have a process in a pid namespace have the same ns0 and ns2 pid as pids are only unique within their pidns.

[Stéphane Graber (stgraber)]

Without looking at the code again (traveling), I believe the best way to fix this is to use even more magic kernel features :)

1) Change the container detection code.
   Rather than compare the two pids we should instead be looking for the inode of /proc/<ns0 pid>/ns/pid and compare it /proc/self/ns/pid. If it doesn't match, we're in a different pidns, regardless of what the pid is.

   This check should be more reliable in general and wouldn't need to have us use the "new" core_pattern field.

2) Use a ucred to send the pid to the apport process in the container.

   A ucred is a special kernel structure which can be sent over a unix socket and which may contain a pid, uid and gid. This is sent through the out of bound communication mechanism of Linux's unix socket implementation.

   ucreds are great for this because any of their field will be translated by the kernel when you read it. So if you set the pid to the host pid, it will be translated to whatever the value is in your pidns. It's also tamper proof. You can only set the pid, uid and gid, to valid values which you own or have privileges over.

The main issue is going to figure out how to send and read ucreds in python.
I've done it many many times in C and Go, but I don't know if python's socket API exposes that kind of low level functionality.

[Tyler Hicks (tyhicks)]

I've assigned CVE-2017-14177 for "Issue 1: Incomplete fix for CVE-2015-1324".

I'm waiting for more information from Sander Bos regarding issues #2 and #3 before assigning any additional CVEs.

[Stéphane Graber (stgraber)]

Attaching what should be a fix for the container handling code.

This does two things:

 1) It stops assuming that argv[1] != argv[4] means that the crash occurred in a container as this check was getting false positives from host software using pidns (chrome) as well as false negatives from a container process that happens to have the same pid as the host process.

Instead, we're now checking whether we got a separate global pid. If we did, we check whether the crashed process shares mntns and pidns with the apport process (usually hostns). If the crashed process shares either namespace with the host, we consider it as not being a container crash and will process it as a host process crash, replacing the local pid with the global pid before continuing.

This ensures that a crash coming from an application that uses a pidns only will still get handled by apport as normal (pidns would differ, mntns wouldn't).

 2) When sending the crash to apport inside the container, we're now doing the following:
   1) Send a ucred as out-of-band data
   2) Send a fd as out-of-band data
   3) Send the arguments as normal data

   Apport in the container will then look for the ucred and if found, will override the pid in the arguments string with the pid found in the ucred.

   This allows for backward compatibility both ways. A container can run a newer apport and will just move on if the ucred is missing or the host can run a newer apport and the container will still get what it expects.

   When both are up to date, the message being sent now will use the ucred's pid field to get kernel level translation of the crashed process' pid. So apport in the container will be getting a pid that makes sense in its namespace as derived from the global pid, rather than using the crashed process' view of the pid.

The attached patch is against Ubuntu 16.04's version of apport and was tested on a 16.04 system.

[Brian Murray (brian-murray)]

Here's a debdiff for artful. I'm not attached to either changelog bullet point if they can be better worded.

[Brian Murray (brian-murray)]

Here's the debdiff for zesty.

[Brian Murray (brian-murray)]

Here's the debdiff for xenial.

[Tyler Hicks (tyhicks)]

I've assigned CVE-2017-14179 for "Issue 2: Apport lacking container / PID namespace support"
I've assigned CVE-2017-14180 for "Issue 3: Apport broken container / PID namespace support"

[Tyler Hicks (tyhicks)]

Thanks Brian. Do you plan on attaching a Trusty debdiff to fix CVE-2017-14177 and CVE-2017-14180 (the incorrect pid comparison to detect in-container crashes)?

[Brian Murray (brian-murray)]

Here's the debdiff for trusty.

[Brian Murray (brian-murray)]

Here's a debdiff with container support disabled since we found an issue with it.

[Brian Murray (brian-murray)]

The corresponding zesty debdiff.

[Brian Murray (brian-murray)]

The xenial one.

[Brian Murray (brian-murray)]

And trusty.

[Brian Murray (brian-murray)]

My most recent set of patches tried to maintain backwards compatibility with previous versions of apport but that actually won't work. The following change needs to be made.

363 # Simply log an entry in the host error log and exit 0.
364 if len(sys.argv) in (5, 6):
365 host_pid = int(sys.argv[-1])
366

Should be:

363 # Simply log an entry in the host error log and exit 0.
364 if len(sys.argv) == 6:
365 host_pid = int(sys.argv[5])
366

[Launchpad Janitor (janitor)]

This bug was fixed in the package apport - 2.20.4-0ubuntu4.7

---------------
apport (2.20.4-0ubuntu4.7) zesty-security; urgency=medium

  * SECURITY UPDATE: Denial of service via resource exhaustion and
    privilege escalation when handling crashes of tainted processes
    (LP: #1726372)
    - When /proc/sys/fs/suid_dumpable is set to 2, do not assume that
      the user and group owning the /proc/<PID>/stat file is the same
      user and group that started the process. Rather check the dump
      mode of the crashed process and do not write a core file if its
      value is 2. Thanks to Sander Bos for discovering this issue!
    - CVE-2017-14177
  * SECURITY UPDATE: Denial of service via resource exhaustion,
    privilege escalation, and possible container escape when handling
    crashes of processes inside PID namespaces (LP: #1726372)
    - Change the method for determining if a crash is from a container
      so that there are no false positives from software using PID
      namespaces. Additionally, disable container crash forwarding by
      ignoring crashes that occur in a PID namespace. This functionality
      may be re-enabled in a future update. Thanks to Sander Bos for
      discovering this issue!
    - CVE-2017-14180

 -- Brian Murray <email address hidden> Thu, 09 Nov 2017 15:36:32 -0800

[Launchpad Janitor (janitor)]

This bug was fixed in the package apport - 2.20.7-0ubuntu3.4

---------------
apport (2.20.7-0ubuntu3.4) artful-security; urgency=medium

  * SECURITY UPDATE: Denial of service via resource exhaustion and
    privilege escalation when handling crashes of tainted processes
    (LP: #1726372)
    - When /proc/sys/fs/suid_dumpable is set to 2, do not assume that
      the user and group owning the /proc/<PID>/stat file is the same
      user and group that started the process. Rather check the dump
      mode of the crashed process and do not write a core file if its
      value is 2. Thanks to Sander Bos for discovering this issue!
    - CVE-2017-14177
  * SECURITY UPDATE: Denial of service via resource exhaustion,
    privilege escalation, and possible container escape when handling
    crashes of processes inside PID namespaces (LP: #1726372)
    - Change the method for determining if a crash is from a container
      so that there are no false positives from software using PID
      namespaces. Additionally, disable container crash forwarding by
      ignoring crashes that occur in a PID namespace. This functionality
      may be re-enabled in a future update. Thanks to Sander Bos for
      discovering this issue!
    - CVE-2017-14180

 -- Brian Murray <email address hidden> Tue, 14 Nov 2017 08:37:05 -0800

[Launchpad Janitor (janitor)]

This bug was fixed in the package apport - 2.20.1-0ubuntu2.12

---------------
apport (2.20.1-0ubuntu2.12) xenial-security; urgency=medium

  * SECURITY UPDATE: Denial of service via resource exhaustion and
    privilege escalation when handling crashes of tainted processes
    (LP: #1726372)
    - When /proc/sys/fs/suid_dumpable is set to 2, do not assume that
      the user and group owning the /proc/<PID>/stat file is the same
      user and group that started the process. Rather check the dump
      mode of the crashed process and do not write a core file if its
      value is 2. Thanks to Sander Bos for discovering this issue!
    - CVE-2017-14177
  * SECURITY UPDATE: Denial of service via resource exhaustion,
    privilege escalation, and possible container escape when handling
    crashes of processes inside PID namespaces (LP: #1726372)
    - Change the method for determining if a crash is from a container
      so that there are no false positives from software using PID
      namespaces. Additionally, disable container crash forwarding by
      ignoring crashes that occur in a PID namespace. This functionality
      may be re-enabled in a future update. Thanks to Sander Bos for
      discovering this issue!
    - CVE-2017-14180

 -- Brian Murray <email address hidden> Thu, 09 Nov 2017 15:50:08 -0800

[Launchpad Janitor (janitor)]

This bug was fixed in the package apport - 2.14.1-0ubuntu3.27

---------------
apport (2.14.1-0ubuntu3.27) trusty-security; urgency=medium

  * SECURITY UPDATE: Denial of service via resource exhaustion and
    privilege escalation when handling crashes of tainted processes
    (LP: #1726372)
    - When /proc/sys/fs/suid_dumpable is set to 2, do not assume that
      the user and group owning the /proc/<PID>/stat file is the same
      user and group that started the process. Rather check the dump
      mode of the crashed process and do not write a core file if its
      value is 2. Thanks to Sander Bos for discovering this issue!
    - CVE-2017-14177
  * SECURITY UPDATE: Denial of service via resource exhaustion,
    privilege escalation, and possible container escape when handling
    crashes of processes inside PID namespaces (LP: #1726372)
    - Change the method for determining if a crash is from a container
      so that there are no false positives from software using PID
      namespaces. Additionally, disable container crash forwarding by
      ignoring crashes that occur in a PID namespace. This functionality
      may be re-enabled in a future update. Thanks to Sander Bos for
      discovering this issue!
    - CVE-2017-14180

 -- Brian Murray <email address hidden> Mon, 13 Nov 2017 08:54:04 -0800

[Stéphane Graber (stgraber)]

Filed an SRU regression bug here https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1732518 to track re-enabling of container support.

[Launchpad Janitor (janitor)]

This bug was fixed in the package apport - 2.20.8-0ubuntu1

---------------
apport (2.20.8-0ubuntu1) bionic; urgency=medium

   * New upstream release:
     - SECURITY UPDATE: Denial of service via resource exhaustion and
       privilege escalation when handling crashes of tainted processes.
     - When /proc/sys/fs/suid_dumpable is set to 2, do not assume that
       the user and group owning the /proc/<PID>/stat file is the same
       owner and group that started the process. Rather check the dump
       mode of the crashed process and do not write a core file if its
       value is 2. Thanks to Sander Bos for discovering this issue!
       (CVE-2017-14177, LP: #1726372)
     - SECURITY UPDATE: Denial of service via resource exhaustion,
       privilege escalation, and possible container escape when handling
       crashes of processes inside PID namespaces.
     - Change the method for determining if a crash is from a container
       so that there are no false positives from software using PID
       namespaces. Additionally, disable container crash forwarding by
       ignoring crashes that occur in a PID namespace. This functionality
       may be re-enabled in a future update. Thanks to Sander Bos for
       discovering this issue!
       (CVE-2017-14180, LP: #1726372)
   * apport/hookutils.py: modify package_versions to return an empty string if
     packages is empty. (LP: #1723822)

 -- Brian Murray <email address hidden> Wed, 15 Nov 2017 12:44:24 -0800