Il ne peut réaliser qu'une version "opportuniste" des pages non exécutables sur architecture i386. Si une zone exécutable doit être située dans l'espace d'adressage linéaire apres une zone non exécutable, alors cette zone non exécutable sera exécutable.
Pour réduire les défauts de cette implémentation, exec-shield essaie de mapper les zones exécutables le plus bas possible en mémoire, (et même dans l'ascii armor a fin d'éviter des return to libc). Cependant, cela n'est pas toujours possible, par exemple dans le cas d'exécutable ET_EXEC (cas de tous les ELFs dans toutes les distributions sauf Adamantix et Trusted Gentoo).
L'autre problème est que l'ascii armor ne stopera pas forcément les return to libc, en effet, à cause du manque d'information de relocation, exec-shield ne peut pas remapper le GOT/PLT d'un fichier ET_EXEC, ces parties ne seront donc pas dans l'armure ascii, il existe des techniques permettant d'attendre l'armure ascii depuis le GOT/PLT à l'aide d'enchainement de return-to-libc (cf. article de Nergal dans phrack).
Comparons ce qui est comparable, PaX n'est pas disponible sur noyau 2.6, seule une partie (l'address space layout randomization l'est). Même dans ce cas, l'ASLR constitue un modèle viable et "autonome" si utilisé avec des exécutables ET_DYN (il est très facile de relinker des exécutables vers ET_DYN) et une solution comme SEGVGUARD alors que exec-shield est toujours assez facilement contournable. Cependant l'ASLR a le defaut de l'information leaking que n'a pas exec-shield: il peut exiter des bugs qui semblent bénins et qui permettent de récupérer les adresses des structures du programme.
Pour résumer: si vous avez un système ET_DYN, ASLR26 sera certainement mieux que exec-shield26, dans les autres cas, les deux permetteront d'empcher certains exploits publiques de marcher. Si vous avez un noyau 2.4, PaX est par contre clairement la meilleure solution.
[^] # Re: autre patch sans controle d'accès pour le noyau 2.6
Posté par Julien . En réponse à la dépêche ASLR pour le noyau 2.6. Évalué à 5.
Il ne peut réaliser qu'une version "opportuniste" des pages non exécutables sur architecture i386. Si une zone exécutable doit être située dans l'espace d'adressage linéaire apres une zone non exécutable, alors cette zone non exécutable sera exécutable.
Pour réduire les défauts de cette implémentation, exec-shield essaie de mapper les zones exécutables le plus bas possible en mémoire, (et même dans l'ascii armor a fin d'éviter des return to libc). Cependant, cela n'est pas toujours possible, par exemple dans le cas d'exécutable ET_EXEC (cas de tous les ELFs dans toutes les distributions sauf Adamantix et Trusted Gentoo).
L'autre problème est que l'ascii armor ne stopera pas forcément les return to libc, en effet, à cause du manque d'information de relocation, exec-shield ne peut pas remapper le GOT/PLT d'un fichier ET_EXEC, ces parties ne seront donc pas dans l'armure ascii, il existe des techniques permettant d'attendre l'armure ascii depuis le GOT/PLT à l'aide d'enchainement de return-to-libc (cf. article de Nergal dans phrack).
Comparons ce qui est comparable, PaX n'est pas disponible sur noyau 2.6, seule une partie (l'address space layout randomization l'est). Même dans ce cas, l'ASLR constitue un modèle viable et "autonome" si utilisé avec des exécutables ET_DYN (il est très facile de relinker des exécutables vers ET_DYN) et une solution comme SEGVGUARD alors que exec-shield est toujours assez facilement contournable. Cependant l'ASLR a le defaut de l'information leaking que n'a pas exec-shield: il peut exiter des bugs qui semblent bénins et qui permettent de récupérer les adresses des structures du programme.
Pour résumer: si vous avez un système ET_DYN, ASLR26 sera certainement mieux que exec-shield26, dans les autres cas, les deux permetteront d'empcher certains exploits publiques de marcher. Si vous avez un noyau 2.4, PaX est par contre clairement la meilleure solution.