Jump to content
Nytro

Exploit Mitigation Techniques on Linux Systems

Recommended Posts

Exploit Mitigation Techniques on Linux Systems

Monday, July 9, 2012

Each year we see phenomenal research works being presented in a number of security conferences and events around the world. Vendors/communities present solutions for existing issues and those on the offensive side present workarounds against these solutions. Eventually this race, between those working on either sides of the coin, helps to make our world a safer place.

Over the last decade, reliable exploitation of memory corruption bugs has become extremely difficult. This has happened, primarily, due to the introduction of various exploit mitigation techniques. In this post, we'll be looking at the current state of exploitation within the Linux environment.

The following security/mitigation techniques are commonly available on most recent distributions:

ASLR

NX

Stack Canaries

FORTIFY_SOURCE

RELRO

PIE

Except for ASLR, which effects system-wide configuration, all of the above techniques are user-space mitigation features that have to be enabled on a per-binary basis. Here is the sample program that we'll be using for our tests:

test-cat.png

Let's have a detailed look at each of the above techniques:

Address Space Layout Randomization - ASLR

Enables randomization of various memory allocation segments (stack, mmap, exec, brk, and vdso). When enabled, each invocation of a binary will have its memory allocations randomized with the available virtual address space. As such, an exploit technique like Ret2libc, that requires static memory addresses of common library functions, is no longer effective.

sys-aslr.png

The randomize_va_space kernel parameter defines system-wide configuration setting for ASLR. This parameter could be set to the following values:

0 - ASLR is turned OFF

1 - ASLR is turned ON (stack randomization)

2 - ASLR is turned ON (stack, heap, and mmap allocation randomization)

Once enabled, each invocation of a program will have different memory locations assigned to it:

sys-aslr-cat-map1.png

sys-aslr-cat-map2.png

In the above output note that all the segments of the /bin/cat process are mapped at different memory locations with each invocation. However, closer look provides an interesting observation. The first three segments that contain .text section of the binary (notice the r-x permissions) are mapped at similar locations each time. We will talk about this behavior in much detail within the PIE section.

Non-Executable Bit (NX)

This feature disallows code execution from marked memory pages/segments. It is also referred to as W^X (W XOR X) due to the fact that the pages marked with this feature could be writable OR executable but not both at the same time. When enabled, a process's memory allocations, that do not contain instructions, will have only rw- permissions assigned to them by default. As such, even if an attacker successfully injects code into a writable memory region through an overflow bug, an attempt to execute code from this section would still fail.

NX is enabled through the MMU by setting bit 63 of the page directory entry. Important thing to note here is that this feature is available only on those systems that have 64bit capability or on those systems that use a PAE-enabled kernel. The Execshield and Grsecurity set of kernel patches could also be used to simulate this behavior when the above requirements could not be met:

test-execstack.png

Note the permissions of the GNU_STACK section in the above output. When we request executable stack through the linker option -z execstack, the GCC compiler marks this section as executable with RWE permissions. On my test system, which is an Ubuntu 10.04 derivative with GCC version 4.4.3, the default command-line disables executable stack markings as evident in the output of first command-line.

Stack Canaries / Stack-Smashing Protection (SSP)

Stack Canaries are a protection feature that safeguard critical program metadata information located on call stack. When enabled, a random canary value is placed on the stack, just below the saved registers from the function prologue. Before a program returns control to its parent, the saved canary value is checked. Any attempts to overwrite the saved return address on the stack will also overwrite the saved cookie and as such the check would fail. In such cases, the __stack_chk_fail function is called, which displays a friendly "stack smashing detected" message and aborts the execution of the program.

This mitigation technique also reorders the placement of local variables on the stack. This is done to ensure that any variable, that effects program control, is placed below a buffer that accepts user-supplied input. Such a placement prevents overwriting of variables placed adjacent to buffers. To read more about other such novel ideas implemented in this protection technique, visit this link: SSP

test-ssp.png

GCC versions 4.x include SSP techniques in its native implementation. Prior 3.x versions had this feature through a patch.

FORTIFY_SOURCE

There are cases when a compiler can correctly estimate the size of a destination operand used in certain string operations. In such cases, the compiler could be requested to replace any vulnerable function calls in the program source with their equivalent safer counterparts. This would eventually make the compiled binary resilient to most overflow attempts without impacting its performance:

test-fortify.png

In the above output you could see that the GCC option -D_FORIFY_SOURCE has been used to include fortifying checks. The call for function printf and gets were replaced with their safer equivalents, __printf_chk and __gets_chk respectively. This option can accept two values:

1 - to enable checks against buffer overflow attacks

2 - to enable checks against buffer overflow and format string attacks

RELocation Read-Only (RELRO)

Another mitigation technique that safeguard against those exploits that require Global Offset Table (GOT) modifications. For this to work, all dynamic symbol resolutions, requested by a binary, have to be carried out before the program execution begins. Once this is done, the GOT could be marked as read-only, thus preventing any runtime modifications.

By default, when we use the GCC linker option -Wl,-z,relro, PLT (Procedure Linking Table) entries, which include references for library functions within a process's memory allocation, are marked as writable (lazy-linking). All other GOT entries apart from PLT remain read-only, providing what is know as Partial-RELRO support:

test-relro.png

The -z,now option ensures that PLT entries are resolved immediately before execution, thus allowing the entire GOT to be marked as read-only. This ensure that Full-RELRO support is enabled for the compiled program.

Position-Independent Executable (PIE)

This feature helps to load a program at a random memory location on each invocation. With ASLR enabled, the stack, heap, and mmap allocations are automatically randomized. However, like we saw earlier with the /bin/cat binary, the .text and other sections of a program are still loaded at static addresses. To make all sections of a program to load at random addresses, we need to compile it with PIE support:

test-pie.png

Programs compiled with this feature are marked as shared relocatable, much similar to shared object libraries used in dynamic linking. To read more, visit this link: PIE

Enabling these mitigation techniques will definitely improve the overall security posture of a system, it still does not make it bullet-proof. Some of these techniques might break compatibility with legacy applications, while others might not work as expected. Different distributions use different default configuration settings and as such you can not simply standardize. The most suitable option would be to test your application code first hand with each of these options, carefully considering the tradeoffs and using only those that provide that rare mix of security and usability.

Author: 7h3rAm at 11:22 PM

Sursa: 7h3rAm's InfoSec Ramblings: Exploit Mitigation Techniques on Linux Systems

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...