Stack Guard Page Circumvention Affecting Multiple Packages
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".
What is a stack guard page?
What is the flaw?
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
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.
A 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?
Product | Package | Advisory/Update |
---|---|---|
Red Hat Enterprise Linux 7 | kernel | RHSA-2017:1484 |
Red Hat Enterprise Linux 7 | kernel-rt | RHSA-2017:1616 |
Red Hat Enterprise Linux 7 | glibc | RHSA-2017:1481 |
Red Hat Enterprise Linux 7.2 Extended Update Support** | kernel | RHSA-2017:1485 |
Red Hat Enterprise Linux 7.2 Extended Update Support** | glibc | RHSA-2017:1479 |
Red Hat Enterprise Linux 6 | kernel | RHSA-2017:1486 |
Red Hat Enterprise Linux 6 | glibc | RHSA-2017:1480 |
Red Hat Enterprise Linux 6.7 Extended Update Support** | kernel | RHSA-2017:1487 |
Red Hat Enterprise Linux 6.7 Extended Update Support** | glibc | RHSA-2017:1479 |
Red Hat Enterprise Linux 6.6 Advanced Update Support*** | kernel | RHSA-2017:1488 |
Red Hat Enterprise Linux 6.6 Advanced Update Support*** | glibc | RHSA-2017:1479 |
Red Hat Enterprise Linux 6.5 Advanced Update Support*** | kernel | RHSA-2017:1489 |
Red Hat Enterprise Linux 6.5 Advanced Update Support*** | glibc | RHSA-2017:1479 |
Red Hat Enterprise Linux 6.4 Advanced Update Support*** | kernel | RHSA-2017:1490 |
Red Hat Enterprise Linux 6.4 Advanced Update Support*** | glibc | RHSA-2017:1479 |
Red Hat Enterprise Linux 6.2 Advanced Update Support*** | kernel | RHSA-2017:1491 |
Red Hat Enterprise Linux 5 ELS* | kernel | RHSA-2017:1482 |
Red Hat Enterprise Linux 5 ELS* | glibc | RHSA-2017:1479 |
Red Hat Enterprise Linux 5.9 Advanced Update Support*** | kernel | RHSA-2017:1483 |
Red Hat Enterprise Linux 5.9 Advanced Update Support*** | glibc | RHSA-2017:1479 |
RHEL Atomic Host | kernel | Images respun on 21June2017 |
Red Hat Enterprise MRG 2 | kernel-rt | RHSA-2017:1647 |
Red Hat Virtualization Hypervisor (RHV-H) Image 3.6 | kernel | RHEA-2017:1569 |
Red Hat Enterprise Virtualization (RHEV-H) Hypervisor 3.6 | kernel | RHBA-2017:1568 |
Red Hat Enterprise Virtualization Manager (RHEV-M) Appliance 3.6 | kernel | RHBA-2017:1571 |
Red Hat Virtualization Hypervisor (RHV-H) Image 4.1 | kernel | RHBA-2017:1566 |
Red Hat Virtualization Manager (RHV-M) Appliance 4.1 | kernel | RHEA-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.
30 Comments
Subscriber exclusive content
A Red Hat subscription provides unlimited access to our knowledgebase, tools, and much more.
Current Customers and Partners
Log in for full access
Log InNew to Red Hat?
Learn more about Red Hat subscriptions
The script needs to be fixed up. In the output I receive:
When I believe it should be:
In which case, line 920 needs to be fixed up to have:
or put an 's' at the end of the $installed_package part of the string...
Hi Ted,
On the referred line is missing a 's' in the variable name:
Original Line: echo -e "Detected 'glibc' package is '${BOLD}$installed_package${RESET}'."
Fix: echo -e "Detected 'glibc' package is '${BOLD}$installed_packages${RESET}'."
Output:
./cve-20171000366-1.shThis script is primarily designed to detect CVE-1000366 on supported Red Hat Enterprise Linux systems and kernel packages. Result may be inaccurate for other RPM based systems.
Detected 'glibc' package is 'glibc-2.12-1.209.el6_9.1.x86_64'. Detected 'kernel' package is '2.6.32-696.3.1.el6.x86_64'.
Hi Ted. Thanks for reporting the issue. There were some last minute changes which were not properly tested. The fixed version of the script is uploaded now. We are sorry for the inconvenience.
Mine wasn't detecting glibc as vulnerable. The part that strips the arch out was changing "glibc-2.5-123.el5_11.3" to "glibc-2.5-123.el5_11". I made these changes to fix it. (The diff includes the previously mentioned missing 's' in a variable name, too).
Hi Brent. Thanks for reporting the issue and suggesting the patch. There were some last minute changes to the algorithm and we did not test them on RHEL5. Sorry about that. The fixed version of the script is uploaded now.
Is it right to assume that this will only partially solve/cover the problem as it is for live kernel patching and this issue covers kernel/glibc, unless kpatch now provides userspace live patching of glibc?
You are correct. Currently the kpatch solution is available for kernel packages only, and does not provide glibc fixes.
Note, there are obvious edits to this document with the insertion of the words 'originally' and 'sequential' displaying with different fonts throughout.
Thanks for noticing. I fixed those that I saw. Regards,
That will teach me for editing on a system with very few fonts ;) Most of the fonts fell back to a single font and I didnt notice.
When will be the "patch" of the script uploaded or updated to version 1.1?
Hi Oscar. I am sorry it took so long. The fixed version of the script is available now.
It would really help to describe the attack vector here for customers. The https://access.redhat.com/security/cve/cve-2017-1000364 says LOCAL and COMPLEX but some plain english description of this on this page would be VERY helpful if it can be described here.
Gday Tom,
Updated the article to include the attack vector header. Is that what you were after ?
Some feedback about the posted Ansible playbooks... it would be nice if this playbook links instead linked to a git repo that could be viewed/browsed (eg. github/gitlab).
Downloading and extracting a tarball to view some basic yaml is tedious. If it's viewable online it can be used to quickly assist admins in determining the complexity of the fix (ie. quick, technical, coded summary).
The script didn't work for me.
Update I change the permissions to file and it worked.
Hi Laval. Can you give a bit more detail about how did the script fail? Does it print any error messages?
I have deployed this to several hosts and it all looks OK, but may have found an issue with Oracle DB Clusterware not starting with this specific kernel. When the kernel update was backed out/reverted to previous kernel (two alternate versions tried) the services started fine again. Have relinked Oracle binaries with new kernel and the issue persists.
Clusterware starts without issue on the following kernels (kernels that were reverted to)
As soon as we moved to the version listed with this errata, the issue occurs (with very little relevant log output).
Clusterware version is 12.1.0.2. Have raised this with Oracle. If anyone else can drop a message if they have any similar issues it would be appreciated. Not 100% it's related at the moment, but isn't as expected.
I am aware of one ongoing issue which Red Hat Kernel Engineering is tracking. That is the following bugzilla:
Bug 1463241 - rlimit_stack problems after update to 3.10.0-514.21.2.el7 - https://bugzilla.redhat.com/show_bug.cgi?id=1463241
Please open a support ticket with Red Hat to investigate your specific circumstances.
This Tomcat issue can be added to the list too:
https://access.redhat.com/solutions/3091371
Interesting discussion here about the upstream patch differing from that used by the distros:
http://seclists.org/oss-sec/2017/q2/568
We just had the exact JVM issue (as above link describes) occur in our application platform
The original post in the referenced thread (subject: stackguard fix in Red Hat and Ubuntu kernels) has a reproducer as an attachment sk.c. When built and run on RHEL 6 and RHEL 7 (both the latest kernel), it produced "Bus error (core dumped)".
Have seen the reproducer.
This post mentions that it's fixed in Linus's tree but this isn't the same version of the fix that was shipped by distros.
http://seclists.org/oss-sec/2017/q2/565
With this in mind, can we expect a revised fix in the near future?
More reports confirming the Oracle DB Clusterware issue have turned up on the Oracle Community Forums
https://community.oracle.com/thread/4058097
Also OMS and OEM client
https://community.oracle.com/thread/4057668
It appears that all the affected Oracle apps modify the ulimit stack settings in startup/execution as shown in commonenv file in the OMS/OEM link above.
This main article really should link to the Java/tomcat issue that PixelDrift and others have mentioned. We were just burned by the Java problem too and it took quite a bit of searching to turn up 3091371.
There is another example here:
https://access.redhat.com/solutions/3098341
Messages like the following (or core dumps) are the common symptom:
We have found that it is almost always a 'wrapper' or equivalent 'environment' bash script that ships with the product that is modifying the ulimit setting for stack to an arbitrary number.
Something like this:
The real problem is that these static ulimit settings are all through various wrapper scripts for different products.
The above Red Hat Knowledgebase links to a Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1463241
Which suggests a fix exists and is currently in testing.
I think this page needs the status changed from 'resolved' with the current outstanding (known) issues.
Acknowledgement (of sorts) of the issue with the released 3.10.0-514.21.2 kernel and OracleDB 12c from Oracle here:
Stack Clash vs. Oracle Database: On the importance of testing Linux OS bug fixes and updates
There is now an updated/revised fix available.. perhaps this page should be updated?
3.10.0-514.26.2.el7 changelog
Hi, Is this vulnerability locally exploitable only? Like I can rely on the internal controls we have in place
Reason behind is some of our environments' kernel is impacted with the vulnerability. I'm just assessing if there is a value of applying the patch now when I will be migrating them to a new environment in the coming month.
Hi Jay, Within the article under section - What are the attack vectors? - we state: 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.
While we are aware of Proof of Concepts created by Qualys that are local only attacks, we cannot exclude remote, even if that has not been proven yet.