Le fourre-tout à Geo

Aller au contenu | Aller au menu | Aller à la recherche

mercredi, octobre 28 2009

test d'EMET, un nouvel outil pour protéger vos programmes

L'annonce est parue hier sur le blog de Microsoft Security Research & Defense: la release d'EMET(Enhanced Mitigation Evaluation Toolkit), un outil gratuit permettant d'appliquer des protections comme DEP sur vos programmes.

Jusqu'ici, l'ajout de ces protections était soumis au bon vouloir du développeur. Soit on activait les options dans Visual Studio, soit on utilisait ma bidouille avec peflags. EMET permet d'activer les protections chez vous, sur les processus que vous voulez de façon très simple: EMET_conf --add <executable>. Quel que soit le dossier contenant votre programme, EMET se chargera de le lancer avec les protections choisies.

EMET gère ainsi une liste de processus et leur apporte les protections suivantes:

  • SEHOP (Structured Exception Handler Overwrite Protection): validation de la chaines des gestionnaires d'exception
  • DEP (Data Execution Prevention): marque certaines parties de la mémoire, par exemple la stack, comme non exécutables
  • NULL page allocation: protection contre les "NULL dereferences" en résevant la première page mémoire
  • Heap spray allocation: "heap spray" est une attaque qui consiste à balancer du shellcode un peu partout dans la mémoire, et à sauter plus ou moins au hasard dans les zones mémoires affectées en espérant pouvoir exécuter le shellcode. EMET réserve les adresses mémoire généralement utilisées dans les exploits pour les empêcher d'y écrire.

Bon, maintenant, les critiques (j'ai bien appris la présentation classique thèse/antithèse/synthèse à l'école, maintenant, j'applique!):

  • J'aurais bien aimé voir ASLR(Address Source Layout Randomization) là-dedans, parce que ça va bien avec DEP et SEHOP.
  • On ne peut pas choisir quelle protection on applique à quel binaire: les options sont dans des clefs registres dans HKLM/Software/Microsoft/EMET, et quand on en désactive une, on la désactive pour tous les programmes. Par contre, il y a une clef registre assez fun nommée "heap_pages", qui permet d'indiquer à EMET quelles adresses réserver pour la partie heap spray allocation.
  • Ce serait sympa d'avoir une interface "oh, look, shiny!", même si ça sert à rien :)

Comparé à peflags, EMET apporte la protection contre les null pointer dereferences et les heap sprays, et permet de protéger un exécutable en se basant sur son nom. Par contre, peflags permet d'appliquer les protections beaucoup plus finement (par exemple, SEHOP pour un programme et pas pour l'autre), et peut ajouter le flag ASLR (qui doit être appliqué sur toutes les DLLs chargées par un programme pour fonctionner correctement).

En résumé, un outil sympa, mais qui devrait être travaillé encore un peu. Ca reste un programme utile pour les développeurs qui veulent tester le comportement de leur application lorsque les protections sont activées. Dommage, c'est déjà fait avec VLC media player!

lundi, septembre 21 2009

Enable DEP and ASLR with MinGW

Every now and then, we see reports about vulnerabilities in numerous applications: buffer overflows and heap overflows are unfortunately very common. Until we find a way to teach all the developers how to think about security while coding (and then, there will still be a lot of programs to fix), we can try some tricks to prevent exploitation of vulnerabilities.These tricks have been Visual Studio only for a long time (and even with VS, not everybody uses them), but now, we have tools to protect as well programs built with GCC.

DEP and ASLR?

DEP provides support for NX bit since Windows XP SP2 and Windows 2003 SP1. This feature flags some part of the memory, like the heap and the stack, as not executable. Then, the shellcodes stored in buffers will have a hard time trying to run.

ASLR randomizes the address of function entry points. This way, exploits with hardcoded functions address like ret2libc attacks won't work.

These two mechanisms are not silver bullets: they can be bypassed. But it makes the process of writing an exploit much harder.

Using it

If you build your program with Visual Studio, it's easy and documented. If you're using MinGW to build for Windows, it's not really documented, but it's easy too.

To mark an executable as DEP and/or ASLR compatible, you have to change the DllCharacteristics field in the Portable Executable header. You can write your own PE modification software, or use one of these two solutions:

Peflags

Peflags is a program you can find in the rebase package from Cygwin. Peflags builds fine with MinGW in MSYS, but you have to tweak a bit the source if you want to run it from Linux, or directly take my modified source.

It is really easy to use:

peflags --dynamicbase=true --nxcompat=true myexecutable

You can add this command to your Makefile. It has to run on the executable and all the dlls it loads, to be effective. If you want to verify that your program has enabled the flags, do:

objdump -p myexecutable

And look for the DllCharacteristics flag. If its value is 140, congratulations! Your executable is now compatible. You can also verify with Process Explorer, from SysInternals. Here is the line for VLC media player:

DEP and ASLR

LD

In March 2009, the support for this DllCharacteristics flag was added to ld, but the new binutils package containing the updated ld hasn't been released (yet). The command line is more or less the same.

Remarks

  • You have to add the flags to every executable used by your program. If you load a vulnerable dll without DEP, it won't protect you.
  • I'll say it again: it's no silver bullet. You still have to fix your bugs. It's a lot harder to exploit, but some may be able to do it.
  • VLC media player now has peflags in its building toolchain! I'm waiting for the release of the next binutils, and then I'll use the new ld.