Kernel Local Privilege Escalation "Dirty COW" - CVE-2016-5195
Updated
Was this information helpful?
Red Hat Product Security has been made aware of a vulnerability in the Linux kernel that has been assigned CVE-2016-5195. This issue was publicly disclosed on October 19, 2016 and has been rated as Important. This issue is being refered to as "Dirty COW" in the media.
Background Information
A race condition was found in the way the Linux kernel's memory subsystem handled the copy-on-write (COW) breakage of private read-only memory mappings. An unprivileged local user could use this flaw to gain write access to otherwise read-only memory mappings and thus increase their privileges on the system.
This could be abused by an attacker to modify existing setuid files with instructions to elevate privileges. An exploit using this technique has been found in the wild. This flaw affects most modern Linux distributions.
Red Hat Product Security has rated this update as having a security impact of Important.
Impacted Products
The following Red Hat Product versions are impacted:
- Red Hat Enterprise Linux 5
- Red Hat Enterprise Linux 6
- Red Hat Enterprise Linux 7
- Red Hat Enterprise MRG 2
- Red Hat Openshift Online v2
- Red Hat Virtualization (RHEV-H/RHV-H)
Attack Description and Impact
This flaw allows an attacker with a local system account to modify on-disk binaries, bypassing the standard permission mechanisms that would prevent modification without an appropriate permission set. This is achieved by racing the madvise(MADV_DONTNEED) system call while having the page of the executable mmapped in memory.
Diagnose your vulnerability
Take Action
All Red Hat customers running the affected versions of the kernel are strongly recommended to update the kernel as soon as patches are available. Details about impacted packages as well as recommended mitigation are noted below. A system reboot is required in order for the kernel update to be applied.
Updates for Affected Products
The fixes for CVE-2016-5195 were included in the recent release of Red Hat Enterprise Linux 7.3.
A kpatch for customers running Red Hat Enterprise Linux 7.2 or greater will be available. Please open a support case to gain access to the kpatch.
For more details about what a kpatch is: Is live kernel patching (kpatch) supported in RHEL 7?
Product | Package | Advisory/Update |
---|---|---|
Red Hat Enterprise Linux 7 | kernel | RHSA-2016:2098 |
Red Hat Enterprise Linux 7 | kernel-rt | RHSA-2016:2110 |
Red Hat Enterprise Linux 7.1 Extended Update Support* | kernel | RHSA-2016:2118 |
Red Hat Enterprise Linux 6 | kernel | RHSA-2016:2105 |
Red Hat Enterprise Linux 6.7 Extended Update Support* | kernel | RHSA-2016:2106 |
Red Hat Enterprise Linux 6.6 Advanced Update Support** | kernel | RHSA-2016:2128 |
Red Hat Enterprise Linux 6.5 Advanced Update Support** | kernel | RHSA-2016:2120 |
Red Hat Enterprise Linux 6.4 Advanced Update Support** | kernel | RHSA-2016:2133 |
Red Hat Enterprise Linux 6.2 Advanced Update Support** | kernel | RHSA-2016:2132 |
Red Hat Enterprise Linux 5 | kernel | RHSA-2016:2124 |
Red Hat Enterprise Linux 5.9 Advanced Update Support** | kernel | RHSA-2016:2126 |
Red Hat Enterprise Linux 5.6 Advanced Update Support** | kernel | RHSA-2016:2127 |
RHEL Atomic Host | kernel | images respun on 3Nov2016 |
Red Hat Enterprise MRG 2 | kernel-rt | RHSA-2016:2107 |
Red Hat Virtualization (RHEV-H/RHV-H) | kernel | pending |
*An active EUS subscription is required for access to this patch.
Please contact Red Hat sales or your specific sales representative for more information if your account does not have an active EUS subscription.
What is the Red Hat Enterprise Linux Extended Update Support Subscription?
**An active AUS subscription is required for access to this patch in RHEL AUS.
Mitigation
Red Hat Support supplies mitigations like SystemTap scripts as a stop-gap until official patches are released. SystemTap scripts are only supported for 30 days after the GA release of the final patches.
HOW TO BUILD AND USE THE SYSTEMTAP WORKAROUND
The systemtap countermeasure involves creating a kernel module (like a driver) using a systemtap script that intercepts the vulnerable system call. It is used as a stopgap solution until a fixed kernel is booted into the affected machine. This solution does not require a reboot and applies to RHEL 5, 6 and 7.
It is not possible to make a module that applies to all kernels. Not even for a family (i.e., All RHEL5, 6 or 7). Each specific kernel version requires a .ko generated for that given kernel (uname -r).
REQUIREMENTS
In order to build the systemtap module, the following packages are required:
- systemtap-client
- systemtap-devel
- gcc (and dependencies)
- kernel-devel-`uname -r`
- kernel-debuginfo-`uname -r`
- kernel-debuginfo-common-`uname -r`
WARNING: The 'kernel' packages requires the same version as the running kernel. Downloading the latest version will prevent systemtap for working. Please download the exact running version.
WHERE DO I GET THE DEBUGINFOS
Please refer to KB https://access.redhat.com/solutions/9907
HOW DO I BUILD THE MODULE
1. After you installed the packages, create a file named dirtycow.stp with this content:
probe kernel.function("mem_write").call ? { $count = 0 } probe syscall.ptrace { // includes compat ptrace as well $request = 0xfff } probe begin { printk(0, "CVE-2016-5195 mitigation loaded") } probe end { printk(0, "CVE-2016-5195 mitigation unloaded") }
2. Save the file. Compile it using this command:
# stap -g -p 4 -m dirtycow_`uname -r|tr -cd [:digit:]` dirtycow.stp dirtycow_26183985.ko
In the above example, the .ko file has a number identifying its kernel version. In that case, it is 2.6.18-398.el5. This module can be used in other systems with this exact kernel version without having to install the debuginfo and development packages, needing only systemtap-runtime . Just copy the module file to the server with the same kernel version, install the systemtap-runtime package and proceed from the next step.
3. In order to load the module, run the command staprun -L <.ko file>. For example:
# staprun -L dirtycow_26183985.ko
4. Check if is it loaded:
# dmesg | grep CVE-2016-5195 CVE-2016-5195 mitigation loaded
5. To unload the module, reboot the system or run the "staprun -A dirtycow_26183985" command and interrupt it with Ctlr+C, as shown below:
# staprun -A dirtycow_26183985 ^C Message from syslogd@... kernel:CVE-2016-5195 mitigation unloaded
IMPORTANT
- The module does not survive a boot: It is not reloaded after a system boot.
- After a reboot, the module must be manually loaded again.
- If the kernel is updated or changed, this module won't be loaded into the new kernel.
- If you booted into a different kernel without the fix, a new compatible module should be loaded.
- A corrected kernel does not need the module load.
Please reference bug 1384344 for detailed mitigation steps.
Comments