Bonjour à tous,

Tout d'abord merci et bravo d'avoir fait de ce forum ce qu'il est.

Après avoir installé le patch de sécurité PaX / GRSecurity, j'ai fait les tests proposés par PaX via la commande : 
paxtest blackhat
J'ai fait le même teste sur Fedora Core 10.
Les résultats sont assez édifiants... aucune protection n'est donnée au kernel depuis une Ubuntu, si ce n'est qu'à la compilation (depuis GCC4) où une vérification d'une attaque de type stack smashed detected (donc pour éviter l'exécution en pile d'un code arbitraire)

Depuis la version patché du kernel (2.6.25-16-grsec) les protections restent insuffisantes contre des attaques locales.

Le résultat est explicable par les options de compilation du noyau & l'installation de patch. Sur le forum ubuntu, je me pose la question du pourquoi, ici je demanderais plutôt la question : quels sont les patchs appliqués ?

PS : Je ne cite pas Fedora/Redhat mais Fedora car les informations selon son uname sont : 
Linux vmfedora 2.6.27.5-117.fc10.i686 #1 SMP Tue Nov 18 12:19:59 EST 2008 i686 i686 i386 GNU/Linux
On voit clairement que les options du noyau sont spécifiques à Fedora Core 10. fc10

PS2 : copier/coller par rapport au forum Ubuntu, à quelques détails près.

---- Fedora 10
PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>
Released under the GNU Public Licence version 2 or later

Mode: blackhat
Linux vmfedora 2.6.27.5-117.fc10.i686 #1 SMP Tue Nov 18 12:19:59 EST 2008 i686 i686 i386 GNU/Linux

Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable anonymous mapping (mprotect)  : Vulnerable
Executable bss (mprotect)                : Killed
Executable data (mprotect)               : Killed
Executable heap (mprotect)               : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Executable stack (mprotect)              : Vulnerable
Anonymous mapping randomisation test     : 16 bits (guessed)
Heap randomisation test (ET_EXEC)        : 13 bits (guessed)
Heap randomisation test (ET_DYN)         : 13 bits (guessed)
Main executable randomisation (ET_EXEC)  : No randomisation
Main executable randomisation (ET_DYN)   : No randomisation
Shared library randomisation test        : No randomisation
Stack randomisation test (SEGMEXEC)      : 19 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 19 bits (guessed)
Return to function (strcpy)              : Vulnerable
Return to function (strcpy, RANDEXEC)    : Vulnerable
Return to function (memcpy)              : Vulnerable
Return to function (memcpy, RANDEXEC)    : Vulnerable
Executable shared library bss            : Vulnerable
Executable shared library data           : Killed
Writable text segments                   : Vulnerable
---- Ubuntu 8.10 
PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>
Released under the GNU Public Licence version 2 or later

Mode: blackhat
Linux vmkubuntu 2.6.27-7-generic #1 SMP Fri Oct 24 06:42:44 UTC 2008 i686 GNU/Linux

Executable anonymous mapping             : Vulnerable
Executable bss                           : Vulnerable
Executable data                          : Vulnerable
Executable heap                          : Vulnerable
Executable stack                         : Vulnerable
Executable anonymous mapping (mprotect)  : Vulnerable
Executable bss (mprotect)                : Vulnerable
Executable data (mprotect)               : Vulnerable
Executable heap (mprotect)               : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Executable stack (mprotect)              : Vulnerable
Anonymous mapping randomisation test     : 16 bits (guessed)
Heap randomisation test (ET_EXEC)        : 13 bits (guessed)
Heap randomisation test (ET_DYN)         : 13 bits (guessed)
Main executable randomisation (ET_EXEC)  : 10 bits (guessed)
Main executable randomisation (ET_DYN)   : 10 bits (guessed)
Shared library randomisation test        : 10 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 19 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 19 bits (guessed)
Return to function (strcpy)              : Vulnerable
Return to function (strcpy, RANDEXEC)    : Vulnerable
Return to function (memcpy)              : Vulnerable
Return to function (memcpy, RANDEXEC)    : Vulnerable
Executable shared library bss            : Vulnerable
Executable shared library data           : Killed
Writable text segments                   : Vulnerable
[...]
tu recupere le src.rpm de ton kernel (yumdownloader --source kernel je crois), tu l'install, et dans le fichier spec tu vera la liste des patch appliqués (yen a pas mal)
J'ai trouvé la réponse à ma question. En réalité c'est une

question de logique :
Prenons un exemple typique de code vulnérable à un buffer

overflow : 
 cat << EOF > vuln.c
#include <string.h>
int main(int argc, char *argv[])
{
  char buff[256];
  strcpy(buff,argv[1]);
  return( 0 );
}
EOF
Compilons le sous Ubuntu :
gcc vuln.c -o vuln
Exécutons le sous Ubuntu, en dépassant la taille de la variable

buff : 
./vuln $(python -c "print 'A'*300")
En sortie de la console, nous avons dans le cas Ubuntu : 
*** stack smashing detected ***: ./vuln terminated
Alors que sous Fedora, les mêmes opérations renvoie l'erreur classique : 
Segmentation fault
Sur Ubuntu la protection est en amont, c'est à dire grâce au compilateur alors que sur Fedora la protection est en aval, c'est à dire sur le kernel.
L'avantage de la protection par GCC est qu'elle protège l'exécutable en lui même, et que le noyau est plus léger, en revanche rien n'empêche à un programme compilé sur une autre version de GCC et d'être exécuter afin d'attaquer le noyau.

L'avantage de la protection sur le Kernel est qu'il reste protégé même avec un programme compilé de l'extérieur le désavantage est d'avoir à appliquer une multitude de patch, donc d'ajout de couche sur le noyau... ce qui n'empêche pas les attaques.

Pour faire simple, d'une part on protège le noyau et d'autre part on empêche les attaques sur le noyau. J'imagine que les deux combinés pourrait donner un résultat trop lourd et trop restrictif.