Ingo Molnar [interview] has announced a new kernel-based security feature for Linux/x86 called "Exec Shield". He describes the patch, which is against the 2.4.20-rc1 kernel, as:

"The exec-shield feature provides protection against stack, buffer or function pointer overflows, and against other types of exploits that rely on overwriting data structures and/or putting code into those structures. The patch also makes it harder to pass in and execute the so-called 'shell-code' of exploits. The patch works transparently, ie. no application recompilation is necessary."

Ingo goes on to provide a lengthy and quite informative description of Exec Shield, beginning with a little background describing the problem that the patch works to fix. This is followed with a longer section devoted to describing how the solution has been implemented, followed by an examination of its limitations. The final section describes how the patch is installed and used. Read on for Ingo's excellent writeup, and some of the resulting discussion.

From: Ingo Molnar
To: linux-kernel mailing list
Subject: [Announcement] "Exec Shield", new Linux security feature
Date: Fri, 2 May 2003 12:37:23 -0400 (EDT)

We are pleased to announce the first publically available source code
release of a new kernel-based security feature called the "Exec Shield",
for Linux/x86. The kernel patch (against 2.4.21-rc1, released under the
GPL/OSL) can be downloaded from:

	http://redhat.com/~mingo/exec-shield/

The exec-shield feature provides protection against stack, buffer or
function pointer overflows, and against other types of exploits that rely
on overwriting data structures and/or putting code into those structures.
The patch also makes it harder to pass in and execute the so-called
'shell-code' of exploits. The patch works transparently, ie. no
application recompilation is necessary.

Background:
-----------

It is commonly known that x86 pagetables do not support the so-called
executable bit in the pagetable entries - PROT_EXEC and PROT_READ are
merged into a single 'read or execute' flag. This means that even if an
application marks a certain memory area non-executable (by not providing
the PROT_EXEC flag upon mapping it) under x86, that area is still
executable, if the area is PROT_READ.

Furthermore, the x86 ELF ABI marks the process stack executable, which
requires that the stack is marked executable even on CPUs that support an
executable bit in the pagetables.

This problem has been addressed in the past by various kernel patches,
such as Solar Designer's excellent "non-exec stack patch". These patches
mostly operate by using the x86 segmentation feature to set the code
segment 'limit' value to a certain fixed value that points right below the
stack frame. The exec-shield tries to cover as much virtual memory via the
code segment limit as possible - not just the stack.

Implementation:
---------------

The exec-shield feature works via the kernel transparently tracking
executable mappings an application specifies, and maintains a 'maximum
executable address' value. This is called the 'exec-limit'. The scheduler
uses the exec-limit to update the code segment descriptor upon each
context-switch. Since each process (or thread) in the system can have a
different exec-limit, the scheduler sets the user code segment dynamically
so that always the correct code-segment limit is used.

the kernel caches the user segment descriptor value, so the overhead in
the context-switch path is a very cheap, unconditional 6-byte write to the
GDT, costing 2-3 cycles at most.

Furthermore, the kernel also remaps all PROT_EXEC mappings to the
so-called ASCII-armor area, which on x86 is the addresses 0-16MB. These
addresses are special because they cannot be jumped to via ASCII-based
overflows. E.g. if a buggy application can be overflown via a long URL:

  http://somehost/buggy.app?realyloooooooooooooooooooong.123489719875

then only ASCII (ie. value 1-255) characters can be used by attackers. If
all executable addresses are in the ASCII-armor, then no attack URL can be
used to jump into the executable code - ie. the attack cannot be
successful. (because no URL string can contain the \\0 character.) E.g. the
recent sendmail remote root attack was an ASCII-based overflow as well.

With the exec-shield activated, and the 'cat' binary relinked into the the
ASCII-armor, the following layout is created:

  $ ./cat-lowaddr /proc/self/maps
  00101000-00116000 r-xp 00000000 03:01 319365     /lib/ld-2.3.2.so
  00116000-00117000 rw-p 00014000 03:01 319365     /lib/ld-2.3.2.so
  00117000-0024a000 r-xp 00000000 03:01 319439     /lib/libc-2.3.2.so
  0024a000-0024e000 rw-p 00132000 03:01 319439     /lib/libc-2.3.2.so
  0024e000-00250000 rw-p 00000000 00:00 0
  01000000-01004000 r-xp 00000000 16:01 2036120    /home/mingo/cat-lowaddr
  01004000-01005000 rw-p 00003000 16:01 2036120    /home/mingo/cat-lowaddr
  01005000-01006000 rw-p 00000000 00:00 0
  40000000-40001000 rw-p 00000000 00:00 0
  40001000-40201000 r--p 00000000 03:01 464809     locale-archive
  40201000-40207000 r--p 00915000 03:01 464809     locale-archive
  40207000-40234000 r--p 0091f000 03:01 464809     locale-archive
  40234000-40235000 r--p 00955000 03:01 464809     locale-archive
  bfffe000-c0000000 rw-p fffff000 00:00 0

In the above layout, the highest executable address is 0x01003fff, ie.
every executable address is in the ASCII-armor.

this means that not only the stack is non-executable, but lots of
mmap()-ed data areas and the malloc() heap is non-executable as well.  
(some data areas are still executable, but most of them are not.)

the first 1MB of the ASCII-armor is left unused to provide NULL pointer
dereference protection and leave space for 16-bit emulation mappings used
by XFree86 and others.

Compare this with the memory layout without exec-shield:

  08048000-0804b000 r-xp 00000000 16:01 3367       /bin/cat
  0804b000-0804c000 rw-p 00003000 16:01 3367       /bin/cat
  0804c000-0804e000 rwxp 00000000 00:00 0
  40000000-40012000 r-xp 00000000 16:01 3759       /lib/ld-2.2.5.so
  40012000-40013000 rw-p 00011000 16:01 3759       /lib/ld-2.2.5.so
  40013000-40014000 rw-p 00000000 00:00 0
  40018000-40129000 r-xp 00000000 16:01 4058       /lib/libc-2.2.5.so
  40129000-4012f000 rw-p 00111000 16:01 4058       /lib/libc-2.2.5.so
  4012f000-40133000 rw-p 00000000 00:00 0
  bffff000-c0000000 rwxp 00000000 00:00 0

In this layout none of the executable areas are in the ASCII-armor, plus
the exec-limit is 0xbfffffff (3GB) - ie. including all userspace mappings.

Note that the kernel will relocate every shared-library to the
ASCII-armor, but the binary address is determined at link-time. To ease
the relinking of applications to the ASCII-armor, Arjan Van de Ven has
written a binutils patch (binutils-2.13.90.0.18-elf-small.patch), which
adds a new 'ld' flag "ld -melf_i386_small" (or "gcc -Wl,-melf_i386_small")
to relink applications into the ASCII-armor. (The patch can be found at
the exec-shield URL as well.)

Overhead:
---------

the patch was designed to be as efficient as possible. There's a very
minimal (couple of cycles) tracking overhead for every PROT_MMAP
system-call, plus there's the 2-3 cycles cost per context-switch.

Limitations:
------------

This feature will not protect against every type of attack.

E.g. if an overflow can be used to overwrite a local variable which
changes the flow of control in a way that compromises the system. But we
do believe that this feature will stop every attack that is purely
operating by overflowing the return address on the stack, or overflowing a
function pointer in the heap. Furthermore, exec-shield makes it quite hard
to mount a successful attack even in the other cases, because it inhibits
the execution of exploit shell-code, in most cases.

also, if the overflow is within the exec-shield itself (e.g. within the
data section of one of the shared library objects in the ASCII-armor) then
the overflow might be possible to exploit.

All in one, exec-shield is one barrier against attacks, not blanket 100%
protection in any way. The most efficient security can be provided by
installing as many layers as possible.

To provide as good protection as possible, there's no trampoline
workaround in the exec-shield code - ie. exec-limit violations in the
trampoline case are never let through. Applications that need to rely on
gcc trampolines will have to use the per-binary ELF flag to make the stack
executable again. (The ELF flag is the same as used by Solar Designer's
non-exec stack patch, to provide as much compatibility with existing
non-exec-stack installations as possible.)

The exec-shield feature will uncover applications that incorrectly assumed
that PROT_READ allows execution on x86. One such example is the XFree86
module loader. The latest XFree86 on rawhide.redhat.com fixes this
problem. For those who cannot install the XFree86 bugfix at the moment
there's a workaround added by the patch, which can be activated via:

    echo 1 > /proc/sys/kernel/X-workaround

This will make every iopl() using application (such as X) have the
exec-shield disabled. Other applications (sendmail, etc.) will still have
the exec-shield enabled. This workaround is default-off. We strongly
encourage to solve this problem by upgrading X, or by using the 'chkstk'
utility to make X's stack forced-executable.

Using it:
---------

Apply the exec-shield-2.4.21-rc1-B6 kernel patch to the 2.4.21-rc1 kernel,
recompile & install the kernel and reboot into it, that's all.

There is a new boot-time kernel command line option called exec-shield=,
which has 4 values. Each value represents a different level of security:

 exec-shield=0    - always-disabled
 exec-shield=1    - default disabled, except binaries that enable it
 exec-shield=2    - default enabled, except binaries that disable it
 exec-shield=3    - always-enabled

the current patch defaults to 'exec-shield=2'. The security level can also
be changed runtime, by writing the level into /proc:

  echo 0 > /proc/sys/kernel/exec-shield

IMPORTANT: security-relevant applications that were started while the
exec-shield was disabled, will have an executable stack and will thus have
to be restarted if the exec-shield is enabled again.

I've also uploaded a modified version of Solar Designer's chstk.c code,
which adds the options necessary to change the 'enable non-exec stack' ELF
flag:

  $ ./chstk
  Usage: ./chstk OPTION FILE...
  Manage stack area executability flag for binaries

    -e    enable execution permission
    -E    enable non-execution permission
    -d    disable execution permission
    -D    disable non-execution permission
    -v    view current flag state

ie. there are two distinct flags, one for forcing an executable stack, one
for forcing a non-executable stack. If both flags are zero then the binary
will follow the system default.

ie. it's possible to use an exec-shield level of 1, and enable the
non-exec stack on a per binary basis, by using the 'exec-shield=1' boot
option and changing binaries one at a time:

   ./chstk -E /usr/sbin/sendmail

(People migrating production environments to an exec-shield kernel might
prefer this variant.)

anyway, comments, suggestions and test feedback is welcome.

	Ingo



From: Davide Libenzi
Subject: Re: [Announcement] "Exec Shield", new Linux security feature
Date: Fri, 2 May 2003 10:12:56 -0700 (PDT)

On Fri, 2 May 2003, Ingo Molnar wrote:

>
> We are pleased to announce the first publically available source code
> release of a new kernel-based security feature called the "Exec Shield",
> for Linux/x86. The kernel patch (against 2.4.21-rc1, released under the
> GPL/OSL) can be downloaded from:
>
> 	http://redhat.com/~mingo/exec-shield/
>
> The exec-shield feature provides protection against stack, buffer or
> function pointer overflows, and against other types of exploits that rely
> on overwriting data structures and/or putting code into those structures.
> The patch also makes it harder to pass in and execute the so-called
> 'shell-code' of exploits. The patch works transparently, ie. no
> application recompilation is necessary.

[ very cool stuff ]

Ingo, do you want protection against shell code injection ? Have the
kernel to assign random stack addresses to processes and they won't be
able to guess the stack pointer to place the jump. I use a very simple
trick in my code :

#define MAX_STKSHIFT 1024

struct thrunner {
	int (*proc)(void *);
	void *data;
}

static int thread_runner(void *data) {
	struct thrunner *thr = data;

	alloca(myrand(MAX_STKSHIFT));
	return thr->proc(thr->data);
}

int my_thread_create(int (*proc)(void *), void *data) {
	struct thrunner *thr;
	...
	thr->proc = proc;
	thr->data = data;
	pthread_create(..., thread_runner, thr, ... );
	...
}

int main(int argc, char *argv[]) {

	mysrand();
	...
}

Same thing can be done for non threaded programs :

int main(int argc, char *argv[]) {

	mysrand();
	alloca(myrand(MAX_STKSHIFT));
	return real_main(argc, argv);
}

Yes, there's still the possibility that an attacker get lucky ( this get
lower increasing MAX_STKSHIFT ) and yes you waste some stack space. But,
oh well, it works w/out any kernel modification and it's portable on all
systems that have alloca().

- Davide



From: Arjan van de Ven
Subject: Re: [Announcement] "Exec Shield", new Linux security feature
Date: 02 May 2003 19:18:21 +0200

> Ingo, do you want protection against shell code injection ? Have the
> kernel to assign random stack addresses to processes and they won't be
> able to guess the stack pointer to place the jump. I use a very simple
> trick in my code :

stack randomisation is already present in the kernel, in the form of
cacheline coloring for HT cpus...



From: Ingo Molnar
Subject: Re: [Announcement] "Exec Shield", new Linux security feature
Date: Fri, 2 May 2003 13:32:20 -0400 (EDT)

On 2 May 2003, Arjan van de Ven wrote:

> > Ingo, do you want protection against shell code injection ? Have the
> > kernel to assign random stack addresses to processes and they won't be
> > able to guess the stack pointer to place the jump. I use a very simple
> > trick in my code :
> 
> stack randomisation is already present in the kernel, in the form of
> cacheline coloring for HT cpus...

we could make it even more prominent than just coloring, to introduce the
kind of variability that Davide's approach introduces. It has to be a
separate patch obviously. This would further reduce the chance that a
remote attack that has to guess the stack would succeed on a random box.

	Ingo

From: Matthias Andree
Subject: Re: [Announcement] "Exec Shield", new Linux security feature
Date: Fri, 2 May 2003 19:05:28 +0200

On Fri, 02 May 2003, Ingo Molnar wrote:

> We are pleased to announce the first publically available source code
> release of a new kernel-based security feature called the "Exec Shield",
> for Linux/x86. The kernel patch (against 2.4.21-rc1, released under the
> GPL/OSL) can be downloaded from:

Am I the only one under the impression that this looks as though this
had waited for OpenBSD 3.3 to say "Blbrrrrrrrrp! we're first to have
stack protection in the kernel and don't need to hack gcc." (Their W^X
isn't enabled on the i386 architecture, but is due (on i386) in 3.4.)



From: Marc-Christian Petersen
Subject: Re: [Announcement] "Exec Shield", new Linux security feature
Date: Fri, 2 May 2003 19:12:04 +0200

On Friday 02 May 2003 19:05, Matthias Andree wrote:

Hi Matthias,

> Am I the only one under the impression that this looks as though this
> had waited for OpenBSD 3.3 to say "Blbrrrrrrrrp! we're first to have
> stack protection in the kernel and don't need to hack gcc." (Their W^X
> isn't enabled on the i386 architecture, but is due (on i386) in 3.4.)
hehehe ;) Well, they cannot say this even w/o exec shield b/c 
www.grsecurity.net. :)

ciao, Marc

From: Carl-Daniel Hailfinger
Subject: Re: [Announcement] "Exec Shield", new Linux security feature
Date: Fri, 02 May 2003 23:48:33 +0200

Ingo Molnar wrote:
> 
> Furthermore, the kernel also remaps all PROT_EXEC mappings to the
> so-called ASCII-armor area, which on x86 is the addresses 0-16MB. These
[snipped]
> In the above layout, the highest executable address is 0x01003fff, ie.
> every executable address is in the ASCII-armor.

If my math is correct,
0x01000000 is 16 MB boundary
0x01003fff is outside the ASCII-armor.

Another question:
Last time I checked, there were some problems with binary only drivers
(to name one, NVidia graphics) and a non-executable stack. Has this been
resolved?

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/



From: Ingo Molnar
Subject: Re: [Announcement] "Exec Shield", new Linux security feature
Date: Sat, 3 May 2003 02:52:21 -0400 (EDT)

On Fri, 2 May 2003, Carl-Daniel Hailfinger wrote:

> Ingo Molnar wrote:
> > 
> > Furthermore, the kernel also remaps all PROT_EXEC mappings to the
> > so-called ASCII-armor area, which on x86 is the addresses 0-16MB. These
> [snipped]
> > In the above layout, the highest executable address is 0x01003fff, ie.
> > every executable address is in the ASCII-armor.
> 
> If my math is correct,
> 0x01000000 is 16 MB boundary
> 0x01003fff is outside the ASCII-armor.

the ASCII-armor, more precisely, is between addresses 0x00000000 and
0x0100ffff. Ie. 16 MB + 64K. [in the remaining 64K the \\0 character is in
the second byte of the address.] So the 0x01003fff address is still inside 
the ASCII-armor.

> Another question: Last time I checked, there were some problems with
> binary only drivers (to name one, NVidia graphics) and a non-executable
> stack. Has this been resolved?

i'm not using any binary-only drivers, so i have no idea. But as long as
they use PROT_EXEC areas for code, they should be safe.

	Ingo



From: Carl-Daniel Hailfinger
Subject: Re: [Announcement] "Exec Shield", new Linux security feature
Date: Sat, 03 May 2003 11:56:47 +0200

Ingo Molnar wrote:
> On Fri, 2 May 2003, Carl-Daniel Hailfinger wrote:
> 
> 
>>Ingo Molnar wrote:
>>
>>>Furthermore, the kernel also remaps all PROT_EXEC mappings to the
>>>so-called ASCII-armor area, which on x86 is the addresses 0-16MB. These

What happens if the ASCII-armor area is full, i.e. sum(PROT_EXEC sizes)
 >16MB for a given binary (Mozilla comes to mind)? Does loading fail or
does the binary run without any errors, giving the user a false sense of
security?

>>
>>[snipped]
>>
>>>In the above layout, the highest executable address is 0x01003fff, ie.
>>>every executable address is in the ASCII-armor.
>>
>>If my math is correct,
>>0x01000000 is 16 MB boundary
>>0x01003fff is outside the ASCII-armor.
> 
> 
> the ASCII-armor, more precisely, is between addresses 0x00000000 and
> 0x0100ffff. Ie. 16 MB + 64K. [in the remaining 64K the \\0 character is in
> the second byte of the address.] So the 0x01003fff address is still inside 
> the ASCII-armor.

Thanks. However, that brings me to the next question:

01000000-01004000 r-xp 00000000 16:01 2036120    /home/mingo/cat-lowaddr

I was wondering why the executable parts of the binary start at the 16
MB boundary. Is this always the case or just something that happens with
cat? In the first case, that would be bad for any binary with a
contiguous executable area bigger than 64K.

Thanks for answering,
Carl-Daniel



From: Arjan van de Ven
Subject: Re: [Announcement] "Exec Shield", new Linux security feature
Date: 03 May 2003 14:48:35 +0200

On Sat, 2003-05-03 at 11:56, Carl-Daniel Hailfinger wrote:
> Ingo Molnar wrote:
> > On Fri, 2 May 2003, Carl-Daniel Hailfinger wrote:
> > 
> > 
> >>Ingo Molnar wrote:
> >>
> >>>Furthermore, the kernel also remaps all PROT_EXEC mappings to the
> >>>so-called ASCII-armor area, which on x86 is the addresses 0-16MB. These
> 
> What happens if the ASCII-armor area is full, i.e. sum(PROT_EXEC sizes)
>  >16MB for a given binary (Mozilla comes to mind)? Does loading fail or
> does the binary run without any errors, giving the user a false sense of
> security?

the binary will run without errors. And all the libs are still below the
main binary (the space for that is much bigger, like 128Mb) so the
executable limit is still the end of the main binary.
>  
> > the ASCII-armor, more precisely, is between addresses 0x00000000 and
> > 0x0100ffff. Ie. 16 MB + 64K. [in the remaining 64K the \\0 character is in
> > the second byte of the address.] So the 0x01003fff address is still inside 
> > the ASCII-armor.
> 
> Thanks. However, that brings me to the next question:
> 
> 01000000-01004000 r-xp 00000000 16:01 2036120    /home/mingo/cat-lowaddr
> 
> I was wondering why the executable parts of the binary start at the 16
> MB boundary. Is this always the case or just something that happens with
> cat? In the first case, that would be bad for any binary with a
> contiguous executable area bigger than 64K.

the start address of the binary is determined by ld at link time. This
cat binary was forced to go at exactly this address.
The patch to binutils in Ingo's directory will add the linker option to
move apps in this area; it will actually use a lower address than
01000000 to allow for bigger binaries. Obviously this 16Mb zone won't
fit all apps, but daemons like sendmail and sshd etc all just fit.

• Online archive of above thread