Per-process user controllable Apport socket file
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Apport |
Fix Released
|
High
|
Unassigned | ||
| apport (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Bug Description
Author: Sander Bos, <https:/
Date: 2019-07-30
As defined in data/apport, when Apport thinks a crash
originated in a container it will forward the crash handling to a
/proc/<
the crashed process:
424 if not is_same_
425 # If the crash came from a container, don't attempt to handle
426 # locally as that would just result in wrong system information.
427
428 # Instead, attempt to find apport inside the container and
429 # forward the process information there.
...
436 try:
437 sock.connect(
Normally, a user can't change the root directory of a process since the
chroot(2) system call can only be used by root / privileged processes.
This also means only processes set up by the super user may have a
different root directory, e.g., legitimate LXC containers, and that root
can trust the value of the root directory.
However, a user can create a user namespace using unshare(2), define
itself root in it, and then in fact be able to use chroot(2). Then,
/proc/<pid>/root/ for that process can lead anywhere. Thus, the root
directory should not be trusted by Apport, since it is user controllable,
meaning the /root/run/
be in fact an actual, legitimate Apport socket file within an actual,
legitimate container.
The same applies to the /run/ directory within the root directory of the
process, even when not using chroot(2): the user can define a /run mount
point within a user namespace when combined with unsharing the mount
namespace (actually equal to what is the case with an actual container
OS), and Apport on the host OS would access that in-namespace mount
point via /proc/<
Thus, both /proc/<pid>/root/ and /proc/<
user-controllable, and neither can be trusted by Apport.
Example of manipulating the root directory via a user namespace:
user@ubuntu$ chroot /bin/ ./busybox sleep 100 # normal situation, chroot(2) not permitted
chroot: cannot change root directory to '/bin/': Operation not permitted
user@ubuntu$ unshare -Ufmpr chroot /bin/ ./busybox sleep 100 # this works
root@ubuntu# readlink /proc/$(pgrep busybox)/root
/bin
Example of manipulating /run/ via a user namespace (the two command
lines are started simultaneously):
user@ubuntu$ echo 'sleep 5; mount -t tmpfs tmpfs /run; touch /run/apport.socket; sleep 5' | unshare -Ufmpr sh
root@ubuntu# sleep 2; ls /proc/$(pgrep unshare)
ls: cannot access '/proc/
/proc/
Thus, per-process, the user controls the socket file (via two separate
path locations, as shown above).
This can for example be abused to "catch" a core dump of a "tainted"
process: for such process a "core" core dump file is normally not
written, and the crash report file in /var/crash/ is created as root.
This makes a user unable to read such core dump, which is intended for
security since it might contain privileged contents. However, using
the methods above the apport.socket file is user controllable and may
for example be an (altered) Apport systemd socket file registered to a
"systemd --user" user initiated systemd process, so that the host Apport
instance can still communicate properly with the socket. Such altered
and user controlled apport.socket file may then for example save the
core dump in a file owned by the user effectively making a tainted,
"privileged" core dump user readable to the user (instead of just to
root) and thus defeating the intention of "fs.suid_
"tainted" core dump non-readable to the user, as root. Due to things
happening in a root user namespace this might be difficult to exploit
for a setuid process, but it it easily doable for non-readable binaries,
as those also fall under the category of "tainted" core dumps.
As a different exploit example, the /proc/<
file may be created as a symbolic link pointing to an arbitrary file
(which could even point to a destination outside the unshared namespace),
for example an actual socket file, enabling other damage / exploitation
scenarios. Apport in this case will follow such symbolic link, and
communicate with the destination (socket) file. This can be abused
into leading to several different consequences. (Side note: even
though /proc/ is used which enables the kernel to "see" the unshared
mount namespace, which seems to be intended behavior, the kernel still
considers the destination of the link relative to its own namespace,
not to the namespace's mount namespace; if this is not intended behavior
but the kernel should see the destination of the link relative to the
mount namespace instead, for example by using the root directory of the
mount namespaces's process, then this might actually be a kernel bug.)
One abuse consequence of the above symlink attack scenario is that a
user is able to both start specific new as well as influence specific
already running specific processes, including root processes and actual
container Apport processes. This on itself could be abused to run as many
processes as root as wished for possibly issuing a system DoS (e.g., due
to "RLIMIT_NPROC" not applying to root), or potentially DoS or shutdown
the sytem via files like or similar in nature to /proc/sysrq-
As a side effect, this can also make the dumping procedure of the crashed
process never-ending, e.g., in case the process started by the receiving
socket keeps running indefinitely (maliously intended or not), or is a
"normal" persistent system process.
As an example of starting a process as root, the following will start
the LXD service (at least in case it was not started already) creating
an LXD network bridge, populating /var/lib/lxd/, et cetera:
user@ubuntu$ echo 'mount -t tmpfs tmpfs /run; ln -s /var/lib/
As another example, linking to /run/lvm/
lvmpolld(8) (as can be seen for example by the appearance of
"Started LVM2 poll daemon." in /var/log/syslog).
Starting processes as a different user, specifically root, is already
harmful on itself; however, actually influnencing (newly created or
already running) (root) processes may lead to more advanced and severe
exploitation methods.
In the above case of LXD for example, interacting with the LXD socket
in its actual API protocol by embedding legitimate LXD commands into
the core dump contents (being arbitrary data defined by the attacker)
and / or ancillary / ucred data (which can partially be defined by the
attacker), all which are sent over the socket by the sending Apport
instance to the destination socket, might be possible. This could lead
to arbitrary commands being issues to the LXD service including creating,
starting, and stopping containers, or even stopping the LXD service as
a whole. The same aspect of sending commands to processes holds true for
other socket files in case of linking to them, e.g., snapd socket files,
which may then also start root processes and / or be able to set up more
complex communication over such socket.
The most notable, and certainly potentially extremely harmful,
example case of communicating with (root) processes is symlinking to
an _actual_ container Apport socket file. This will start an Apport
process (as root) in said container, and communicate the socket data
(which is already "Apport-valid" data) to the receiving Apport instance.
More interestingly, the above can be done in a host-to-container,
container-
leading to for example host-to-container and cross-container dumping.
Exploit scenarios of the above include container escaping, (root)
privilege escalation in (or: into) a container OS, and DoS via system
resource exhaustion or storage resource exhaustion on a container OS.
Note that starting an Apport instance on a (different) container OS via
the above Apport socket-as-asymlink scenario, as well as the above LXD
manipulation scenario, can be considered remote exploitation scenarios:
container OSes (in most cases) are in fact (virtually) distinct systems,
i.e., "remote" to the system on which the attacker operates.
CVE References
| Changed in apport (Ubuntu): | |
| importance: | Undecided → High |
| Changed in apport: | |
| importance: | Undecided → High |
| Stéphane Graber (stgraber) wrote | #1 |
| Seth Arnold (seth-arnold) wrote | #2 |
| Seth Arnold (seth-arnold) wrote | #3 |
| Seth Arnold (seth-arnold) wrote | #4 |
| Stéphane Graber (stgraber) wrote | #5 |
| Stéphane Graber (stgraber) wrote | #6 |
| Stéphane Graber (stgraber) wrote | #7 |
| Stéphane Graber (stgraber) wrote | #8 |
| Stéphane Graber (stgraber) wrote | #9 |
| Changed in apport (Ubuntu): | |
| assignee: | nobody → Canonical Security Team (canonical-security) |
| Changed in apport (Ubuntu): | |
| assignee: | Canonical Security Team (canonical-security) → Ubuntu Security Team (ubuntu-security) |
| Alex Murray (alexmurray) wrote | #10 |
| Changed in apport (Ubuntu): | |
| assignee: | Ubuntu Security Team (ubuntu-security) → Stéphane Graber (stgraber) |
| Stéphane Graber (stgraber) wrote Re: [Bug 1839420] Re: Per-process user controllable Apport socket file | #11 |
| Alex Murray (alexmurray) wrote | #12 |
| Changed in apport (Ubuntu): | |
| assignee: | Stéphane Graber (stgraber) → nobody |
| Stéphane Graber (stgraber) wrote | #13 |
| Launchpad Janitor (janitor) wrote | #14 |
| Changed in apport (Ubuntu): | |
| status: | New → Fix Released |
| information type: | Private Security → Public Security |
| description: | updated |
| tags: | added: id-5d9e45ccd0f15c2eef59e1b0 |
| tags: | added: id-5db7d7dd9955e4200bf58f02 |
| Changed in apport: | |
| milestone: | none → 2.21.0 |
| status: | New → Fix Released |
Sorry for the delay, I'm on vacation this week and so have very limited time to catch up on bug reports.
For the symlink issue, we should have apport do:
- chdir(/
- chroot(
This will avoid any potential symlink attacks by preventing leaving the root of the container.
The other part of the issue is a tad trickier. Thinking about it, the real issue is if you have a world-executable setuid binary as that would then allow dumping the process. If the binary is owned by a user mapped in the user namespace, then it doesn't matter as you don't actually need its setuid bit and can just trace it whichever way you want.
My solution for this issue would be to check whether the executable which spawned the crashed process is owned by a uid/gid that's part of the container's map. If it is, then there is no security concern, if it isn't, then we shouldn't forward.
So to recap, the changes to apport would be:
- Check that uid of TASK_EXE is in TASK_SUBUID, if not, log and exit
- Check that gid of TASK_EXE is in TASK_SUBGID, if not, log and exit
- chdir(TASK_CWD)
- chroot(TASK_ROOT)
- Attempt connect, if not preset/broken symlink, log and exit
It's worth noting that we are specifically NOT attaching to the namespaces of the process here as we don't want to make the host apport visible inside the container as this would pose a further security risk.
Is there an angle of this that I missed which the above changes wouldn't protect against?
If you think those changes would take care of this, I can write a patch for apport tonight, do basic regression testing for the cases that I care about and then let you do more review and landing of this.