"Dirty COW" variant on transparent huge pages - CVE-2017-1000405
Red Hat Product Security has been made aware of a vulnerability in the Linux kernel which has been assigned CVE-2017-1000405. This issue was publicly disclosed on November 29th, 2017 and has been rated as Important.
Background Information
A race condition was found in the way the Linux kernel's memory subsystem handles the copy-on-write (COW) of private read-only huge-page based memory mappings.
An unprivileged local user could use this flaw to gain write access to otherwise read-only memory mappings, and modify read-only pages which can influence how userspace applications behave.
Acknowledgements
Red Hat would like to thank Eylon Ben Yaakov and Daniel Shapiro for reporting this flaw.
Impacted Products
The following Red Hat product versions are impacted:
Red Hat Enterprise Linux 7 for ARM and Red Hat Enterprise Linux for Power LE
Products that are not Impacted
The following Red Hat product versions are not impacted as they did not backport the commit that introduced this issue:
- Red Hat Enterprise Linux 5, 6, 7
- Red Hat Enterprise MRG 2
While Red Hat's Linux Containers are not directly impacted by kernel issues such as this flaw, Red Hat recommends that you use the most recent versions of your container images. The Container Health Index, part of the Red Hat Container Catalog, can always be used to verify the security status of your containers.
Attack Description and Impact
This flaw allows an attacker with a local system account to modify hugepages which would be traditionally considered "read-only", bypassing the standard permission mechanisms that would prevent modification without an appropriate permission set. This is achieved by racing access with touch_pmd with can_follow_write_pmd and the pmd can become 'dirty' without going through a copy on write cycle.
The most rudimentary attack vector available to attackers would be to modify the physical page 0. Application binaries in the ELF format rely on this page being mapped read-only and usable as part of its "BSS" section. Compilers create code expecting variables will be uninitialized (set to 0). By leveraging this issue physical page 0 can be mapped and written to without triggering the COW process and thus break the invariant that every mapping of this page contains only zero values, leading to unexpected and undefined behaviour.
This bug is not as severe as the original "Dirty COW" because of the type of memory page that the attacker can modify. Regular files can not be mapped using transparent huge pages. It may however be possible to escalate privileges by abusing userspace applications that expect the BSS segment to be mapped to zero.
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
Product | Package | Advisory/Update |
|---|---|---|
| Red Hat Enterprise Linux 7 for ARM and Red Hat Enterprise Linux for Power LE | kernel-alt | Pending |
Mitigation
Initial attempts at exploiting this flaw involved modification of page zero and replacing it with user content. Different attack vectors may be discovered please consider which mitigation step is suitable for your environment.Primary mitigation:
It is possible to prevent the zero page from being mapped as a huge page, by modifying a configuration tunable in the /sys directory as shown below. This prevents the flaw from being exercised in this method.
# echo 0 > /sys/kernel/mm/transparent_hugepage/use_zero_page
This option will not persist between reboots and will need to be applied at each system start to be affected.
Secondary mitigation:
It is possible to mitigate this flaw by disabling hugepages on a system. Some user applications may require hugepages to be performant, and may suffer a performance penalty when running without hugepages.
Red Hat has existing solutions created instructing how to disable transparent hugepages.
- How to disable transparent hugepages (THP) on Red Hat Enterprise Linux 7: https://access.redhat.com/solutions/1320153
If your applications require transparent huge pages, please consult your software vendor to confirm.
Ansible Playbook
An Ansible playbook is available. To verify the legitimacy of the script, you can download the detached GPG signature as well.
The playbook runs against a variable named HOSTS, and can be invoked as follows (assuming 'hostname' is defined in your inventory file):
# ansible-playbook -e HOSTS=hostname cve-2017-1000405-mitigate.yml
This playbook requires root privileges so you will need to use an account with appropriate permissions.
Comments