CVE-2017-1000253 - load_elf_binary does not allocate sufficient space
Updated -
- Status
- Resolved
- Impact
- Important
Red Hat Product Security has been made aware of a vulnerability affecting the Linux kernel's implementation of loading ELF binaries. Provided that an application is built as Position Independent Executable (PIE), the loader can allow part of that application's data segment to map over the memory area reserved for its stack resulting in corruption of the stack, with possible privilege escalation. The vulnerability has been assigned CVE-2017-1000253. This issue was publicly disclosed on Tuesday September 26th, 2017 and is rated as Important.
Background Information
Position Independent Executables are a security mechanism intended to increase the difficulty of attackers by allowing for randomizing the memory location of an applications binaries (ELF), libraries and related assets. This is intended to decrease the success of a generic attack by reducing the predictability of data at specific memory locations.
PIE Executable Specifics
Executables can be created with PIE as a compile-time option dictated by the '-pie' flag passed to the compiler.
$ gcc -pie test.c -o test
Existing programs can be determined to be PIE executable using 'readelf' and looking for specific headers. Below is an example of the commands used to verify the previously compiled test executable.
$ readelf -h ./test | grep "Type:[[:space:]]*DYN " Type: DYN (Shared object file) $ readelf -d ./test |grep "(DEBUG)" 0x0000000000000015 (DEBUG) 0x0
Attackers do not need to have the ability to create PIE executables but can leverage existing PIE executables on the system to abuse.
Acknowledgments
Red Hat would like to thank Qualys Research Labs for reporting this flaw.
Additional References
https://www.qualys.com/2017/09/26/cve-2017-1000253/cve-2017-1000253.txt
https://access.redhat.com/blogs/766093/posts/1975793
http://www.trapkit.de/tools/checksec.html
https://en.wikipedia.org/wiki/Position-independent_code#Position-independent_executables
https://sourceware.org/binutils/docs/binutils/readelf.html
Impacted 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 5
- Red Hat Enterprise Linux 6
- Red Hat Enterprise Linux 7 (prior to the 7.4.0 release)
- Red Hat Enterprise MRG 2
Products that are not Impacted
Systems running Red Hat Enterprise Linux 7.4, with kernel versions of kernel-3.10.0-693 or newer
Red Hat's Linux containers inherit kernel flaws from their host's kernel. Red Hat recommends that you use the most recent versions of available 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
The flaw occurs when the kernel attempts to load an ELF executable and it does not correctly calculate the overall size of the required memory. When the kernel load segments of the binary, be mapped into and past the area that is intended to be a gap between the application and the stack
An attacker would need to craft the binary that is being executed to ensure that the correct size allocations take place and, when the data is corrupted, that it is overlayed with a valid and working payload. While the attacker cannot modify kernel instructions, if the attack runs against a targeted privileged userspace application that is setuid, or has additional user capabilites, it may be possible to gain elevated privileges.
An attacker must have access to a local account on the system; this is not a remote attack.
Diagnose your vulnerability
Take Action
All Red Hat customers running 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 take affect.
Updates for Affected Products
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?
* An active premium subscription entitlement is required to request kpatch.
| Product | Package | Advisory |
|---|---|---|
| Red Hat Enterprise Linux 7.3 Extended Update Support** | kernel | RHSA-2017:2793 |
| Red Hat Enterprise Linux 7.2 Extended Update Support** | kernel | RHSA-2017:2794 |
| Red Hat Enterprise Linux 6 | kernel | RHSA-2017:2795 |
| Red Hat Enterprise Linux 6.7 Extended Update Support** | kernel | RHSA-2017:2796 |
| Red Hat Enterprise Linux 6.6 Advanced Update Support*** | kernel | RHSA-2017:2797 |
| Red Hat Enterprise Linux 6.5 Advanced Update Support*** | kernel | RHSA-2017:2798 |
| Red Hat Enterprise Linux 6.4 Advanced Update Support*** | kernel | RHSA-2017:2799 |
| Red Hat Enterprise Linux 6.2 Advanced Update Support*** | kernel | RHSA-2017:2800 |
| Red Hat Enterprise Linux 5 Extended Life Support | kernel | RHSA-2017:2801 |
| Red Hat Enterprise Linux 5.9 Advanced Update Support*** | kernel | RHSA-2017:2802 |
**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
We recommend to test your systems and applications before deploying this mitigation on production systems.
If further assistance is needed please contact Red Hat Global Support Services.
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-1000253-mitigation.yml
This playbook requires root privileges and specifies 'become: true', so you will need to use an account with appropriate permissions.
Subscriber exclusive content
A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.

8 Comments
Subscriber exclusive content
A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.
Current Customers and Partners
Log in for full access
Log InNew to Red Hat?
Learn more about Red Hat subscriptions
The Resolve section would be more helpful if the links actually worked.
Agreed! I get a 404 error for https://access.redhat.com/errata/RHSA-2017:2795
Hi guys, sorry for the inconvenient;
This is happening because the errata is still being pushed to our CDN. Will resolve in the next few hours! Hang tight!
link is not working for me as well.
When Red Hat Enterprise Linux 7.4 version will be released? Our latest version is Red Hat Enterprise Linux Server release 7.3 (Maipo)
Hi Zak. RHEL7.4 already had the included fixes and does not need to take any additional action at this time.
Does the vm.legacy_va_layout mitigation require a reboot? The notes above don't mention that a reboot is required for the mitigation, but the detect script says...
This kernel version is vulnerable. Either update kernel package or apply mitigation and restart the system.
Update: It appears that the restart is not necessary after applying the mitigation. I applied the mitigation, without restarting, and the detect script now says...
Detected kernel package is '3.10.0-514.26.2.el7.x86_64'. This kernel version is vulnerable. You have correct mitigation installed and the kernel vulnerability is not exploitable.
Hi Sam, sorry for the delay in our response. Reboot is not necessary. The vm.legacy_va_layout=1 setting applies to newly launched processes. Exploiting the CVE-2017-1000253 vulnerability requires the attacker to run a new process. Therefore, the mitigation is effective without reboot. We will fix the recommendation in the detection script accordingly.