Ubuntu-fr

saelyx

Sécurité & Ubuntu / Protection de la stack & *overflows

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, mais alors pourquoi sur Ubuntu/Debian si peu de protection au niveau noyau par rapport à une Fedora - à noter au passage que le résultat de paxtest sur OpenSuse est similaire à Ubuntu - devrait-on se poser la question inverse : pourquoi autant de sécurité sur une Fedora ?

PS : Je ne cite pas Fedora/Redhat mais Fedora car les informations selon 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

---- 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

[...]

Dernière modification par saelyx (Le 04/04/2009, à 15:30)

---

-----BEGIN GEEK CODE BLOCK-----
GCS d- s+:+ a? C++ UL+++ P L++ E--- W+ N o-- K- w+ O-- M- V-
PS+ PE Y PGP t 5 X+ R- tv-- b+ DI- D++ G e-- h--- r+++ z+++
------END GEEK CODE BLOCK------

Francois69

Re : Sécurité & Ubuntu / Protection de la stack & *overflows

réflexion intéressante
je ne sais pas... quelqu'un aurait un élement de réponse ?

Dernière modification par Francois69 (Le 03/03/2009, à 12:56)

saelyx_visitor

Re : Sécurité & Ubuntu / Protection de la stack & *overflows

Merci de ton intérêt dès que j'en sais plus je le ferais savoir

castor77

Re : Sécurité & Ubuntu / Protection de la stack & *overflows

Moi aussi je suis intéressé par tes recherches !

---

"I know this music", Le 5ème élément.

saelyx

Re : Sécurité & Ubuntu / Protection de la stack & *overflows

[philo]
Un adage dit : "trop de sécurité mène à l'insécurité."
Il est claire qu'un excès de sécurité ne peut être que néfaste à notre liberté. Nous n'avons pas à nous sentir menacé s'il n'y a pas de menaces. Mais Internet étant devenu ce qu'il est, nous devons nous protéger. Mais à quel prix ?
[/philo]

Pour vous aider, quelques notions de la sécurité BSD :
- emprisonnement des processus dans un chroot (en cas de failles, l'exploitation se limite à l'environnement restreint) ; mots clés : jail process bsd linux patch

- un compte wheel/operator/admin pouvant exécuter des programmes non accessible à un utilisateur lambda :

# ListeApps contient la liste des applications
# qui pourront être lancé à partir d'un compte "admin" 
ListeApps="sudo su ifconfig route dhclient"
for App in ListeApps
do
  chown root.administrateurs $(which $App)
  chmod 4750 $(which $App)
done

Quelques autres durcissement au niveau sécurité sont possibles :
- désactiver les démons (services) inutiles
- dans /etc/ssh/sshd_config , mettre le PermitRootLogin à No
...
Plus de détail sur http://secureinfo.free.fr/1/?id=77

Vous me direz que tout ceci ne protège en rien le noyau, mais une machine n'ayant aucun service exécuté est bien plus difficile à attaquer (à moins d'une faille dans l'implémentation de protocoles réseaux.)

Dernière modification par saelyx (Le 16/03/2009, à 16:43)

---

-----BEGIN GEEK CODE BLOCK-----
GCS d- s+:+ a? C++ UL+++ P L++ E--- W+ N o-- K- w+ O-- M- V-
PS+ PE Y PGP t 5 X+ R- tv-- b+ DI- D++ G e-- h--- r+++ z+++
------END GEEK CODE BLOCK------

saelyx

Re : Sécurité & Ubuntu / Protection de la stack & *overflows

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 les des cas :

*** 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â sur le 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.

Vous protéger votre Stack vous avez aussi les patchs grsecurity.

Dernière modification par saelyx (Le 04/04/2009, à 20:08)

---

-----BEGIN GEEK CODE BLOCK-----
GCS d- s+:+ a? C++ UL+++ P L++ E--- W+ N o-- K- w+ O-- M- V-
PS+ PE Y PGP t 5 X+ R- tv-- b+ DI- D++ G e-- h--- r+++ z+++
------END GEEK CODE BLOCK------

saelyx

Re : Sécurité & Ubuntu / Protection de la stack & *overflows

Pour finir, une note sur la protection de la mémoire :

Memory Protection
Additional access checks have been added so that /dev/mem and /dev/kmem can only be used to access device memory. These changes will help defend against rootkits and other malicious code.

The lower 64K of system memory is no longer addressable by default. This will help defend against malicious code that attempts to leverage kernel bugs into security vulnerabilities.

Applications compiled as Position Independent Executables (PIE) are now placed into memory in unpredictable locations, making it harder for security vulnerabilities to be exploited.

Source : http://www.ubuntu.com/testing/hardy/bet … 07edadc1d7

Dernière modification par saelyx (Le 22/04/2009, à 13:18)

---

-----BEGIN GEEK CODE BLOCK-----
GCS d- s+:+ a? C++ UL+++ P L++ E--- W+ N o-- K- w+ O-- M- V-
PS+ PE Y PGP t 5 X+ R- tv-- b+ DI- D++ G e-- h--- r+++ z+++
------END GEEK CODE BLOCK------