Stack Guard Page Circumvention Affecting Multiple Packages

Public Date: May 22, 2017, 08:14
Updated July 3, 2017, 13:41 - Chinese, Simplified Japanese
Resolved Status
Important Impact

To get released updates to address this issue use the Resolve tab.

Red Hat Product Security has been made aware of a vulnerability affecting Linux systems that allows for privilege escalation. This vulnerability has been assigned two CVE names, CVE-2017-1000364 for the Linux kernel and CVE-2017-1000366 for glibc. This issue was publicly disclosed on June 19th, 2017 and has been rated as Important.

Background Information

Qualys has released a security advisory showing practical methods for circumventing an exploit protection mechanism known as the "stack guard page".  A flaw was found in the way memory was being allocated on the stack for user-space binaries. If heap (or a different memory region) and stack memory regions were adjacent to each other, an attacker could use this flaw to jump over the stack guard page, causing controlled memory corruption on the process stack or the adjacent memory region, thus increasing their privileges on the system.

What is a stack guard page?
Stack guard page was added to the Linux kernel as a protection against stack overflow attacks and primarily to fix CVE-2010-2240. Access to the stack guard page triggers a trap, so it serves as a divider between a stack memory region and other memory regions in the process address space so that sequential stack access cannot be fluently transformed into access to another memory region adjacent to the stack (and vice versa).
What is the flaw?

The stack guard page was originally meant as a protection against sequential memory access. The reporter (Qualys) found ways to re-introduce CVE-2010-2240 in generic binaries not by causing sequential stack overflow (and thus running into the stack guard page), but by leveraging certain constructs in stack memory allocation, as performed by common binaries, to "jump" over the stack guard page and again be able to access memory in the adjacent memory region without causing an invalid access. This results in overlapping stack with another memory region (usually heap) and thus stack memory access is reflected into the heap and vice versa.

What are the fixes? 
To avoid stack guard page jumping, every stack allocation primitive needs to implement freshly allocated memory probing with the stack guard gap size granularity. The existing gcc -fstack-check implementation aims to do exactly that, but currently it is not working correctly. Before the gcc -fstack-check implementation is fixed and all of the exposed binaries are rebuilt, we have a combination of kernel and glibc mitigations that addresses all known reporter-provided exploits available:

  • kernel fix for CVE-2017-1000364 increases the stack guard gap size from one page to 1 MiB to make successful exploitation of this issue more difficult
  • glibc fix for CVE-2017-1000366 blocks the use of LD_LIBRARY_PATH in AT_SECURE=1 programs. This acts as a form of input sanitization for the internal DSO search path construction, which would otherwise perform a very large alloca() with a partially-filled buffer. As additional hardening, the amount of heap and stack allocations performed by the processing of LD_AUDIT, LD_PRELOAD, and LD_HWCAP_MASK has been reduced. Previously, they could be used to shape heap and stack allocations and we believe that, after these changes, this has become more difficult.

What are the attack vectors?

This vulnerability is in fact a class of attacks against a category of memory protections and mitigation mechanisms.  The attacks can be performed through any of the traditionally known attack vectors, however the CVSS scores provided by Red Hat are a worse-case scenario.  We expect the most common form of attack will be attackers with a local account, able to control the conditions in which processes are started.  Network-facing processes may be affected, and Red Hat strongly recommends upgrading the kernel and glibc to minimise these attack vectors.

What are the side effects of these mitigation patches?

At the time of this writing there is a known issue introduced by the kernel patch which creates overlapping values in /proc/meminfo.  This should not affect the functional application of the system and protection provided by the kernel.   A patch to address this issue may be released at a later date.

Some processes which set threads stack guard size manually may not correctly handle the guard page size change and may need to be adjusted to the new changed size (See man pthread_attr_setguardsize) and correctly handle this changed condition.

Acknowledgement

Red Hat would like to thank Qualys Research Labs for reporting this flaw.

Successful exploitation of this vulnerability could allow an attacker to escalate privileges and potentially run malicious code.

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.5
  • Red Hat Virtualization
  • RHEL Atomic Host

Diagnose your vulnerability


Determine if your system is vulnerable

Use the detection script below to determine if your system is currently vulnerable to this flaw.  To verify the legitimacy of the script, you can download the detached GPG signature as well.  The current version of the script is 1.1.

Take Action

All Red Hat customers running affected products are strongly recommended to update as soon as patches are available. Details about impacted packages are noted below. A system reboot is required in order for the kernel update to be applied.

kpatch for customers running Red Hat Enterprise Linux 7.2 or greater is 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?


ProductPackageAdvisory/Update
Red Hat Enterprise Linux 7kernelRHSA-2017:1484
Red Hat Enterprise Linux 7kernel-rtRHSA-2017:1616
Red Hat Enterprise Linux 7glibcRHSA-2017:1481
Red Hat Enterprise Linux 7.2 Extended Update Support**kernelRHSA-2017:1485
Red Hat Enterprise Linux 7.2 Extended Update Support**glibcRHSA-2017:1479
Red Hat Enterprise Linux 6kernelRHSA-2017:1486
Red Hat Enterprise Linux 6glibcRHSA-2017:1480
Red Hat Enterprise Linux 6.7 Extended Update Support**kernelRHSA-2017:1487
Red Hat Enterprise Linux 6.7 Extended Update Support**glibcRHSA-2017:1479
Red Hat Enterprise Linux 6.6 Advanced Update Support***kernelRHSA-2017:1488
Red Hat Enterprise Linux 6.6 Advanced Update Support***glibcRHSA-2017:1479
Red Hat Enterprise Linux 6.5 Advanced Update Support***kernelRHSA-2017:1489
Red Hat Enterprise Linux 6.5 Advanced Update Support***glibcRHSA-2017:1479
Red Hat Enterprise Linux 6.4 Advanced Update Support***kernelRHSA-2017:1490
Red Hat Enterprise Linux 6.4 Advanced Update Support***glibcRHSA-2017:1479
Red Hat Enterprise Linux 6.2 Advanced Update Support***kernelRHSA-2017:1491
Red Hat Enterprise Linux 5 ELS*kernelRHSA-2017:1482
Red Hat Enterprise Linux 5 ELS*glibcRHSA-2017:1479
Red Hat Enterprise Linux 5.9 Advanced Update Support***kernelRHSA-2017:1483
Red Hat Enterprise Linux 5.9 Advanced Update Support***glibcRHSA-2017:1479
RHEL Atomic HostkernelImages respun on 21June2017
Red Hat Enterprise MRG 2kernel-rtRHSA-2017:1647
Red Hat Virtualization Hypervisor (RHV-H) Image 3.6kernelRHEA-2017:1569
Red Hat Enterprise Virtualization (RHEV-H) Hypervisor 3.6kernelRHBA-2017:1568
Red Hat Enterprise Virtualization Manager (RHEV-M) Appliance 3.6kernelRHBA-2017:1571
Red Hat Virtualization Hypervisor (RHV-H) Image 4.1kernelRHBA-2017:1566
Red Hat Virtualization Manager (RHV-M) Appliance 4.1kernelRHEA-2017:1570


*An active ELS 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 ELS subscription.

**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.

Ansible Playbook

An Ansible  playbook is available.

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-1000366.yml

This playbook requires root privileges, so you may need to specify --become if it's not defined for 'hostname' in your inventory file.

Comments