PTRACE_TRACEME - Kernel privilege escalation - CVE-2019-13272

Updated -

Overview

A flaw was found in the way PTRACE_TRACEME functionality was handled in the Linux kernel. This flaw could allow a local, unprivileged user to increase their privileges on the system or cause a denial of service.

Background

The ptrace() system call is found in Unix-based operating systems and allows one process to control another by observing and manipulating another process state. This system call is frequently used for debugging and is rarely used by software in production.

This flaw can be exploited by an unprivileged local user (including malicious code running within a privileged container) to escalate their privileges on the system. The issue has been assigned CVE-2019-13272, with a severity impact of Important.

Affected Products

Red Hat Product Security has rated this update as having a security impact of Important.

The following Red Hat product versions are impacted:

  • Red Hat Enterprise Linux 7-alt
  • Red Hat Enterprise Linux 8
  • Red Hat Atomic Host
  • OpenShift Container Platform 4 (RHEL CoreOS)

Although Red Hat's Linux containers are not directly impacted by host vulnerabilities, their security does rely upon the integrity of the host’s kernel environment. To protect the host system from malicious containers exploiting this vulnerability, ensure that the host system is running a fixed kernel or has had the mitigation applied.

Frequently Asked Questions

Q: Does this affect containers?
A: Unprivileged containers run with podman and docker use a default seccomp policy that prevents use of the ptrace() syscall, which prevents the privilege escalation. Unprivileged containers run in Kubernetes and OpenShift 4 clusters do not use seccomp filtering by default and can use the ptrace() syscall to exploit this vulnerability.

Even if the ptrace() syscall is filtered with seccomp, unprivileged containers can cause a denial of service on the host system (kernel crash) by exploiting this vulnerability. Filtering of ptrace() only prevents privilege escalation.

Q: What are the side effects of denying ptrace?
A: Any tool that relies on the ptrace system call will probably not work correctly. Tools such as debuggers, syscall tracers, and reverse engineering tools may not work correctly.

Q: Does denying ptrace in the host affect my containers?
A: Yes, it is a system-wide mitigation.

Additional Information

Resolution

Red Hat customers running affected versions of the Red Hat products are strongly recommended to update them as soon as errata are available. Customers are urged to apply the appropriate updates immediately.

At this time, there is no reliable method to detect whether the exploit has successfully been run on a system as the exploit leaves no evidence.

Red Hat Product Security strongly recommends customers review the threat profile of their systems and address their higher-profile systems first.

Mitigation

The reproducer example shown in Google Project Zero's example can be mitigated by configuring SELinux to deny ptrace.

Customers are advised to take a risk-based approach to mitigating this issue. Systems that require high degrees of security and trust should be addressed first and should be isolated from untrusted systems until such time as treatments can be applied to those systems to reduce the risk of exploit.

To deny ptrace:

  1. Enable the SELinux “Enforcing” mode.

  2. If necessary, reboot the system to enable SELinux (see Red Hat Enterprise Linux 8 guide on Enabling SELinux).

  3. Configure SELinux to deny ptrace (by default, the deny_ptrace boolean is disabled). The SELinux boolean setting deny_ptrace will deny all processes, even those that are running in unconfined_t domains, from being able to use ptrace() on other processes.
    To deny ptrace, run:

    ~]# setsebool -P deny_ptrace on

    The -P parameter to the setsebool command makes persistent changes. Do not use the -P parameter if you do not want changes to persist across reboots.

  4. Verify that the deny_ptrace boolean is enabled:

    ~]$ getsebool deny_ptrace
deny_ptrace --> on

** Note: Disabling ptrace will also affect the functionality of some userspace utilities that use the ptrace system call (such as gdb and strace) from working correctly. This SELinux boolean can be disabled to allow these tools to work when the kernel has been updated with the setsebool command:

~]# setsebool -P deny_ptrace off

Performance Impact

At this time, there is no known performance impact of disabling ptrace functionality.

Comments