Re: L'ASLR ne sert à rien

ASLR n'est pas très utile.
Déjà, contrairement à ce qui est écrit, il ne rend aléatoire que les adresses dans la pile, et pas le tas (ils ont dû confondre avec les adresses renovoyées pa mmap() quisont, elles, aléatoires). On le voit dans l'article:

$ cat /proc/3027/maps
(...)
0804a000-0806b000 rw-p 0804a000 00:00 0 [heap]
b7da3000-b7da4000 rw-p b7da3000 00:00 0
b7da4000-b7ed2000 r-xp 00000000 03:04 345236 /lib/tls/libc-2.3.6.so
b7ed2000-b7ed7000 r--p 0012e000 03:04 345236 /lib/tls/libc-2.3.6.so
b7ed7000-b7eda000 rw-p 00133000 03:04 345236 /lib/tls/libc-2.3.6.so
b7eda000-b7edc000 rw-p b7eda000 00:00 0
b7ef5000-b7ef8000 rw-p b7ef5000 00:00 0
b7ef8000-b7f0d000 r-xp 00000000 03:04 2032253 /lib/ld-2.3.6.so
b7f0d000-b7f0f000 rw-p 00015000 03:04 2032253 /lib/ld-2.3.6.so
bf7f7000-bf80d000 rw-p bf7f7000 00:00 0 [stack]
ffffe000-fffff000 ---p 00000000 00:00 0 [vdso]Texte


Lors d'un second lancement du même processus, nous constatons que l'adresse de la pile a effectivement changé et se trouve désormais entre 0xBF865000 et BxBF87B000 :

$srv&
[3593]

$ cat /proc/3593/maps
(...)
0804a000-0806b000 rw-p 0804a000 00:00 0 [heap]
b7e11000-b7e12000 rw-p b7e11000 00:00 0
b7e12000-b7f40000 r-xp 00000000 03:04 345236 /lib/tls/libc-2.3.6.so
b7f40000-b7f45000 r--p 0012e000 03:04 345236 /lib/tls/libc-2.3.6.so
b7f45000-b7f48000 rw-p 00133000 03:04 345236 /lib/tls/libc-2.3.6.so
b7f48000-b7f4a000 rw-p b7f48000 00:00 0
b7f63000-b7f66000 rw-p b7f63000 00:00 0
b7f66000-b7f7b000 r-xp 00000000 03:04 2032253 /lib/ld-2.3.6.so
b7f7b000-b7f7d000 rw-p 00015000 03:04 2032253 /lib/ld-2.3.6.so
bf865000-bf87b000 rw-p bf865000 00:00 0 [stack]
ffffe000-fffff000 ---p 00000000 00:00 0 [vdso]Texte

L'adresse de la pile a changé, pas celle du tas. On peut aussi le vérifier avec un programme du style:


/* test.c */

#include <stdlib.h>
#include <stdio.h>


int main(void)
{
int i;
int *p;

p = malloc(10 * sizeof(int));

/* pile */
printf("Dans la pile: %p\n", (void *)&i);
/* tas */
printf("Dans le tas: %p\n", (void *)p);

free(p);

return 0;
}



renvoie:

$ for i in `seq 1 10`; do ./test; done

Dans la pile: 0xbfe185cc
Dans le tas: 0x804a008
Dans la pile: 0xbf99c95c
Dans le tas: 0x804a008
Dans la pile: 0xbfd0d4cc
Dans le tas: 0x804a008
Dans la pile: 0xbf80afcc
Dans le tas: 0x804a008
Dans la pile: 0xbfe485fc
Dans le tas: 0x804a008
Dans la pile: 0xbfbf83ac
Dans le tas: 0x804a008
Dans la pile: 0xbff256dc
Dans le tas: 0x804a008
Dans la pile: 0xbff4df0c
Dans le tas: 0x804a008
Dans la pile: 0xbfa9824c
Dans le tas: 0x804a008
Dans la pile: 0xbfd4dd0c
Dans le tas: 0x804a008


Ensuite, "aléatoire" est un grand mot.
L'une des critiques quand il a été introduit est la suivante:

One of the biggest complaints that has been raised is that the amount of randomization is insufficient. The patches, as posted, vary the stack base within a 64KB area and the mmap() base within a 1MB range. Alignment requirements prevent just any address from being used with the result that only a relatively small number of possible base addresses exists. So a determined attacker could repeatedly run a hardcoded exploit with some assurance that, within a reasonable amount of time, the stack would land at the right place and the exploit would work. Placing a long series of no-op instructions at the beginning of the payload can also make an exploit more robust when faced with randomization.

En gros, la plage de valeur possible n'est pas très étendue, et quand on enlève les adressesquivontpas (alignement toussa...), et bien on se dit qu'il suffit de lancer l'exploit en boucle et au bout de peu de temps on va tomber sur une adresse qui correspond à celle codée dans l'exploit.

Voilà. Après, je ne pense pas qu'il y ait un inpact visible sur les performances. De toute façon, avec la rapidité des machines actuelles, j'en ai rien à foutre de perdre 10% de performances si j'ai un OS fiable et sûr. Une machine à laver marche 24/7, il devrait en être de même d'un ordinateur...