Linux ASLR vulnerability: attackers can disable ASLR (CVE-2016-3672) infinitely)

Source: Internet
Author: User
Tags cve

Linux ASLR vulnerability: attackers can disable ASLR (CVE-2016-3672) infinitely)


Recently, security personnel fixed an old vulnerability in Linux ASLR. Any user with 32-bit application permissions on x86 Devices, you can disable ASLR by setting the RLIMIT_STACK resource to "unlimited.
The vulnerability CVE number is CVE-2016-3672 and CNNVD number is CNNVD-201604-092.
2cto tips:
Aslr) is a security protection technology for buffer overflow. By randomizing the la s of linear zones such as heap, stack, and shared library ing, attackers can increase the difficulty of predicting target addresses, A technology that prevents attackers from directly locating attack code to prevent overflow attacks.
Detection
You can perform the following steps to check whether your system is affected:
1. Create an empty project that displays memory ing:
 

#includeint main(int argc, const char *argv[]){    char cmd[256];    sprintf(cmd, "cat /proc/%d/maps", getpid());    system(cmd);    return 0;}


2. Compile the program:
$ Gcc show_maps.c-o show_maps # In a i386 machine
$ Gcc show_maps.c-o show_maps-m32 # In a 64-bit machine
3. Run this program to check whether ASLR is working:
 

$ for i in `seq 1 10`; do ./show_maps | grep "r-xp.*libc"; donef75c4000-f7769000 r-xp 00000000 08:01 784726     /lib32/libc-2.19.sof75db000-f7780000 r-xp 00000000 08:01 784726     /lib32/libc-2.19.sof7557000-f76fc000 r-xp 00000000 08:01 784726     /lib32/libc-2.19.sof7595000-f773a000 r-xp 00000000 08:01 784726     /lib32/libc-2.19.sof7574000-f7719000 r-xp 00000000 08:01 784726     /lib32/libc-2.19.sof75af000-f7754000 r-xp 00000000 08:01 784726     /lib32/libc-2.19.sof7530000-f76d5000 r-xp 00000000 08:01 784726     /lib32/libc-2.19.sof7529000-f76ce000 r-xp 00000000 08:01 784726     /lib32/libc-2.19.sof75c2000-f7767000 r-xp 00000000 08:01 784726     /lib32/libc-2.19.sof75fe000-f77a3000 r-xp 00000000 08:01 784726     /lib32/libc-2.19.so


ASLR works properly if the ibc-2.19.so library file maps to a random location.
Set the RLIMIT_STACK stack to "unlimited" and run the same check:
 

$ ulimit -a | grep stackstack size              (kbytes, -s) 8192$ ulimit -s unlimitedstack size              (kbytes, -s) unlimited$ for i in `seq 1 10`; do ./show_maps | grep "r-xp.*libc"; done5559a000-5573f000 r-xp 00000000 08:01 784726      /lib32/libc-2.19.so5559a000-5573f000 r-xp 00000000 08:01 784726      /lib32/libc-2.19.so5559a000-5573f000 r-xp 00000000 08:01 784726      /lib32/libc-2.19.so5559a000-5573f000 r-xp 00000000 08:01 784726      /lib32/libc-2.19.so5559a000-5573f000 r-xp 00000000 08:01 784726      /lib32/libc-2.19.so5559a000-5573f000 r-xp 00000000 08:01 784726      /lib32/libc-2.19.so5559a000-5573f000 r-xp 00000000 08:01 784726      /lib32/libc-2.19.so5559a000-5573f000 r-xp 00000000 08:01 784726      /lib32/libc-2.19.so5559a000-5573f000 r-xp 00000000 08:01 784726      /lib32/libc-2.19.so5559a000-5573f000 r-xp 00000000 08:01 784726      /lib32/libc-2.19.so


The libc-2.19.so library file is mapped to the same location, indicating that ASLR is disabled.
This is an old method for disabling ASLR, but unfortunately this problem still exists in the current Linux system.
Vulnerability Overview
When the stack size is set to "unlimited", ASLR Linux randomizes all mmap base addresses. That is to say, when the legacy mode is used to simulate X86_32 on i386 and X86_64, the program only randomizes the stack and executable files, and ignores other mmapped files (library files, vDSO files, etc ), even in some Linux versions, executable files are not randomized.
The mmap_legacy_base () function is used to calculate the location of the library file when the stack size is set to "unlimited:
Static unsigned long mmap_legacy_base (void)
{
If (mmap_is_ia32 ())
Return TASK_UNMAPPED_BASE;
Else
Return TASK_UNMAPPED_BASE + mmap_rnd ();
}
When the system runs on a local 32-bit System (i386) or a 32-bit Simulated System (x86_32), this function does not add any random offset.
Vulnerability Exploitation
An attacker only needs to set the stack size to "unlimited" and then run a 32-bit application. This method is mainly used to run (attack) Elevation of Privilege applications, such as setuid or setgid.
Impact
Attackers with 32-bit application running permissions on the x86 system can exploit this vulnerability to disable ASLR of any application, including setuid and setgid programs. It is not a vulnerability, but a method to disable ASLR. Attackers can use it with other vulnerabilities. Because i386 (Intel 80386) has a high usage rate, the affected systems and users are still very extensive.

Repair
Patches for this vulnerability are as follows:
diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.cindex 96bd1e2..389939f 100644--- a/arch/x86/mm/mmap.c+++ b/arch/x86/mm/mmap.c@@ -94,18 +94,6 @@ static unsigned long mmap_base(unsigned long rnd) }  /*- * Bottom-up (legacy) layout on X86_32 did not support randomization, X86_64- * does, but not when emulating X86_32- */-static unsigned long mmap_legacy_base(unsigned long rnd)-{-   if (mmap_is_ia32())-       return TASK_UNMAPPED_BASE;-   else-       return TASK_UNMAPPED_BASE + rnd;-}--/*  * This function, called very early during the creation of a new  * process VM image, sets up which VM layout function to use:  */@@ -116,7 +104,7 @@ void arch_pick_mmap_layout(struct mm_struct *mm)    if (current->flags & PF_RANDOMIZE)        random_factor = arch_mmap_rnd(); -   mm->mmap_legacy_base = mmap_legacy_base(random_factor);+   mm->mmap_legacy_base = TASK_UNMAPPED_BASE + random_factor;     if (mmap_is_legacy()) {        mm->mmap_base = mm->mmap_legacy_base;

This patch enables randomization of library files, vDSO, and mmap requests on i386 and X86_32 in legacy mode, and will fix this issue in the next Linux version.
 

 

 

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.