Molnár Ingo: Exec Shield for Linux/x86

 ( trey | 2003. május 3., szombat - 8:42 )

Molnár Ingo bejelentése szerint elérhető egy patch (a 2.4.21 RC kernelhez), amely az "Exec Shield" névre hallgat, és egy olyan technikát használ, amely megakadályozza a binárisok ellen intézett puffer túlcsordulás és hasonló támadásokat. Úgy tűnik, hogy a patch védelmet nyújt az exploitok széles skálájával szemben. Védelmet nyújt az ún. "shell-code" exploitokkal szemben is. A folt működése teljesen transzparens, csak a kernelt kell megfoltozni, egyéb alkalmazás újrafordítása nem szükséges hozzá. Hasonló foltok már napvilágot láttak eddig is, ilyen például a Solar Designer által készített "non-exec stack" kernelfolt. Az Exec Shield for Linux/x86 működésben kicsit túlmutat a "non-exec stack patch"-en.

Nem teljesen tiszta, hogy a folt bekerül-e a fejlesztői kernelbe, hiszen korábban Linus ellenséges volt az ilyen típusú foltokkal szemben. Szerinte a "non-executable stack" dolog nem igazán működik. Marcelo - a 2.4.x stabil kernelsorozat karbantartója - eddig többször is bizonyítékát adta a készégességének, lehet, hogy ez a folt is bekerül a 2.4-es szériába? Mindenesetre a Linux disztribútorok ettől függetlenül használhatják, még akkor is, ha nem lesz része a stabil kernelnek.

A folt működésének hátteréről, megvalósításáról, a "mi ellen véd?" kérdésre, stb. Ingo levelében találsz választ:

From: Ingo Molnar
Newsgroups: linux.kernel
Subject: [Announcement] "Exec Shield", new Linux security feature
Date: Fri, 02 May 2003 18:40:23 +0200

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:
[...]

Folytatás itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

hmm. a vege valahogy lemaradt.

tobbek kozt itt [groups.google.com] is elolvashatod.

Kivancsi vagyok hogyan lehetne (van-e ertelme egyaltalan)
osszebaratkoztatni a PaX (address space randomization) project
munkajaval.

Egyebkent az ilyesminek tobb ertelmet latom mint honapokig vadaszni az
strcpy()kre.

És atomtámadás ellen is véd ez az ojjektum?

Amennyiben a patch gondot okoz az mplayer-nek (vagy barmilyen normalis programnak) akkor az nem hiba, amit javitania kell MI-nak?

Per file basis ki lehet kapcsolni ezt a vedelmet. Az senkinek sem a
hibaja hogy nem mukodnek egyutt.

Ezt [marc.theaimsgroup.com] olvastad már?