PaX

PaX est un correctif (patch) de sécurité pour le noyau Linux créé en 2000. Il utilise une approche qui permet aux programmes informatiques de faire seulement ce qu'ils ont à exécuter proprement, et rien de plus.

La protection de l'espace executable est un des mécanismes mis en œuvre. Ainsi chaque segment de la mémoire peut être accédé soit en écriture, soit en exécution, mais jamais les deux.

Cela rend notamment l'exploitation des dépassements de tampon plus difficile à réaliser. Cette restriction, connue sous le nom de NX Bit, existait déjà auparavant au niveau matériel sur certaines architectures, mais PaX en est une implémentation logicielle. D'autres implantations de ce même système existent pour d'autres systèmes d'exploitation dont W^X pour OpenBSD.

Les processeurs récents d'Intel et d'AMD (entre autres) disposent matériellement de ce NX Bit, mais il faut que le système d'exploitation le supporte pour qu'il soit utilisé.

L'autre mécanisme principal de PaX est de rendre aléatoire la valeur de certaines adresses mémoires.

PaX est maintenu par The PaX Team (en français, L'Équipe PaX) ; le principal programmeur de ce groupe est anonyme.

PaX permet de mieux se protéger contre une exploitation malveillante d'erreurs de programmation classiques : notamment Dépassement de tampon, dépassement de valeur d'un entier,

PaX ne détecte pas directement le dépassement de tampon. Pour cela, il existe d'autres mécanismes dont SSP (Stack-Smashing Protector) dans gcc.

PaX peut être utilisé sur les architectures : x86, IA-32, AMD64, IA-64, PA-RISC, MIPS (32 et 64 bits), PowerPC, SPARC (et DEC Alpha).

Les limites de PaX

PaX ne peut pas protéger contre des erreurs de conception dans une application ou dans le système d'exploitation.

Il ne peut pas non plus protéger s'il n'y a pas de contrôle sur les chaînes de caractères saisies, par exemple, une chaine avec un %s ou un %x pour un programme écrit en langage C (voir Format string attack (en)).

La documentation PaX décrit trois classes d'attaques sur lesquelles PaX pourra tenter de vous protéger. La documentation explique ce sur quoi Pax pourra vous protéger et ce sur quoi Pax sera impuissant

En résumé, les attaques que PaX pourra bloquer sont les suivantes :

1. celles qui introduisent et exécutent un code arbitraire (fréquemment via un shellcode) ;
2. celles qui essaient d'exécuter du code déjà existant, mais dans un contexte autre que celui prévu par le programmeur à l'origine (voir return-to-libc attack);
3. celles qui essaient d'exécuter du code avec des données arbitraires.

Protection de zones mémoires contenant du code exécutable

Par l'intermédiaire de PaX, les zones de code ne seront pas accessibles en écriture, ce qui permet de se protéger contre des interventions malicieuses tentant de les modifier. Cela est fait en utilisant (ou émulant) la fonctionnalité du NX Bit.

PAGEEXEC

PAGEEXEC est la première implémentation proposée pour implémenter le bit NX sur les architectures i386. Le bit supervisor surchargé pour émuler le comportement du bit NX. Cette implémentation repose sur le translation lookaside buffer (TLB), le cache utilisé par l'unité de gestion mémoire. Lors d'une tentative d'accès à une page protégée qui n'est pas encore dans le TLB, en exécution, une faute de protection est levée. Comme sur les processeurs récents le TLB est séparé en un cache pour les exécutions (ITLB) et un cache pour les données (DTLB), PaX peut déterminer si il s'agit d'une instruction, qui doit alors être interdite.

SEGMEXEC

SEGMEXEC émule le fonctionnement du bit NX sur les processeurs IA-32. Cela fonctionne en segmentant la mémoire en deux zone de 1.5 Go chacune. La zone basse (de 0 à 1.5 Go) contient les données non exécutables, c'est-à-dire les données mais aussi instructions (qui peuvent en effet vouloir être lues). La seconde zone, exécutable, en revanche ne contient que les instructions. Les mappings des deux segments pointent vers les mêmes zones de la mémoire physique, ainsi la mémoire vive utilisée n'est pas doublée.

Lorsqu'une adresse mémoire doit être exécutée, elle est traduite dans la zone contenant le code exécutable. Si le code n'est pas présent à l'adresse traduite, il s'agit alors d'une tentative d'exécution de code interdite, le programme est alors tué.

Restriction via mprotect()

Voir entre autres (en) mprotect

Trampoline emulation

Les trampolines implémentés par GCC sous la forme de petites portions de code généralement générés sur la pile lors du runtime. Cela nécessite donc de rendre exécutable la pile, ce qu'empêche PaX. Pour éviter que les programmes utilisant cette technique ne soient tués, PaX est capable d'identifier et d'autoriser leur utilisation.

Address space layout randomization

L'address space layout randomization consiste à rendre certaines adresses de la mémoire virtuelle aléatoires permettant de se prémunir contre l'exploitation de certaines failles (généralement de type dépassement de tampon). Les parties du programmes qui seront placés à des adresses aléatoires sont en général la pile, le tas, la position des bibliothèques, …

Rendre aléatoire l'adresse de la pile

Pour éviter une utilisation aléatoire de la Pile d'appel d'un programme, PaX rend cette adresse aléatoire.

Rendre aléatoire l'adresse de base utilisé par mmap() base

Dans un système d'exploitation POSIX, l'appel système mmap() mappe des fichiers ou des périphériques informatiques en mémoire. Rendre aléatoire l'adresse de base utilisée par mmap() permet de se protéger contre certaines exploitations de faille

Base ET_EXEC rendue aléatoire

Marquage des exécutables ELF

PaX permet à des fichiers exécutables au format ELF d'être marqué avec des permissions réduites via les outils chpax et paxctl. Ces marquages sont dans l'en-tête ELF et sont à la fois indépendants du système de fichier et de la partie Code objet du fichier. L'outil chpax est obsolète et remplacé par paxctl.

PaX permet des marquages individuels pour PAGEEXEC et SEGMEXEC, de rendre aléatoire les adresses de base de la pile d'appel, du tas, de mmap(), …

• octobre 2000 : premier version de PaX avec un support basique de PAGEEXEC ;
• novembre 2000 : première mise en œuvre de MPROTECT ;
• juin 2001 : mise en œuvre de l'ASLR, toutefois non publié ;
• juillet 2001 : publication de l'ASLR ;
• août 2001 : amélioration de l'ASLR avec la randomisation de la pile et du PIE ;
• juillet 2002 : publication de RANDEXEC et de VMA Mirroring ;
• octobre 2002 : publication de SEGMEXEC ;
• octobre 2002 : amélioration de l'ASLR avec la randomisation de la base de la pile noyau ;
• février 2003 : introduction du marquage des fichiers ELF ;
• avril 2003 : publication de KERNEXEC ;
• juillet 2003 : amélioration de l'ASLR avec la randomisation de brk ;
• février 2004 : introduction du marquage PT_PAX_FLAGS dans les fichiers ELF ;
• mai 2004 : amélioration des performances de PAGEEXEC ;
• 4 mars 2005 : publication d'une vulnérabilité sur le VMA Mirroring ;
• 1 avril 2005 : PaX Team annonce la fin du développement de PaX, ce qui n'aura pas lieu, faute de candidat à la reprise du développement.