exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

Linux ASLR Weakness Addressed

Linux ASLR Weakness Addressed
Posted Apr 7, 2016
Authored by Hector Marco

A weakness in the Linux ASLR implementation has been addressed.

tags | advisory
systems | linux
advisories | CVE-2016-3672
SHA-256 | dc611674639e17d87db4bc8f7c419a93127da71cfb5a237027c9ffac55a2e504

Linux ASLR Weakness Addressed

Change Mirror Download
CVE-2016-3672 - Unlimiting the stack not longer disables ASLR
Authors: Hector Marco & Ismael Ripoll
CVE: CVE-2016-3672
Dates: April 2016


Description

We have fixed an old and very known weakness in the Linux ASLR implementation.
Any user able to running 32-bit applications in a x86 machine can disable the ASLR by setting the RLIMIT_STACK resource to unlimited.

Following are the steps to test whether your system is vulnerable or not:

1) Create a dummy program which shows its memory map:

#include <stdio.h>

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

2) Compile it:

$ 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 the application to check that ASLR is working

$ for i in `seq 1 10`; do ./show_maps | grep "r-xp.*libc"; done
f75c4000-f7769000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
f75db000-f7780000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
f7557000-f76fc000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
f7595000-f773a000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
f7574000-f7719000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
f75af000-f7754000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
f7530000-f76d5000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
f7529000-f76ce000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
f75c2000-f7767000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so
f75fe000-f77a3000 r-xp 00000000 08:01 784726 /lib32/libc-2.19.so


The libc-2.19.so library is mapped at random positions, so, the ASLR is working properly.
Now, we run the same test but setting the stack to unlimited:


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


The libc-2.19.so library is mapped at the same position in all executions: the ASLR has been disabled.
This is a very old trick to disable ASLR, but unfortunately it was still present in current Linux systems.

Vulnerable packages

The weakness, IFAIK is present from the first version of current Linux GIT repository. The first version on this resposiroty is Linux-2.6.12-rc2 dated on April 2005.

Impact

An attacker capable of running 32-bit system applications in a x86 machine is able to disable the ASLR of any application, including sensitive applications such as setuid and setgid. Note that it is not a exploitable vulnerability by itself but a trick to disable the ASLR. This weakness can be use by an attacker when trying to exploit some other bug. Since the i386 is still very used, the number of systems and affected users could be extremely huge.
The wekaness

The issue arises because the ASLR Linux implementation does not randomize always the mmap base address when the stack size is set to unlimited. Concretely, on i386 and on X86_64 when emulating X86_32 in legacy mode, only the stack and the executable are randomized but not other mmapped files (libraries, vDSO, etc.). And depending in the Linux version, the executable is neither randomized.

The function to calculate the libraries position when the stack is set to unlimited is mmap_legacy_base():


static unsigned long mmap_legacy_base(void)
{
if (mmap_is_ia32())
return TASK_UNMAPPED_BASE;
else
return TASK_UNMAPPED_BASE + mmap_rnd();
}


The function doesn't add any random offset when the system is running in a native 32-bit system (i386) or a 32-bit emulated system (x86_32).
Exploit

To exploit this weakness, the attacker just need to set to unlimited the stack and then execute a 32-bit application. Obviously the idea is to execute (attack) privileged applications such as setuid/setgid.
FIX

We have created a patch to fix this issue:


diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c
index 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;


The patch enables randomization for the libraries, vDSO and mmap requests on i386 and in X86_32 in legacy mode. We already sent the patch to Linux mantainers and the issue will be not problem in incomming Linux versions: Enable full randomization on i386 and X86_32
Discussion

Although this vulnerability is not exploitable by itself, the truth is that the ASLR protection mechanism is useless on local attacks for i386 and x86_32 systems when the attackers are able to attack applications that they can lauch.

Hector Marco - http://hmarco.org

Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    0 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close