Principe des attaques

En novembre 1996, le paysage de la sécurité informatique a été modifié à tout jamais !

Le guide de la liste de diffusion Bubtraq, AlephOne, rédigea un article pour le magazine Phrack Magazine (numéro 49) intitulé "Smash The Stack For Fun And Profit".

Cet article a eu un effet dévastateur sur l'état de la sécurité car il expliquait clairement comment des pratiques de programmation déplorables pouvaient conduire à des mises en danger en termes de sécurité par l'intermédiaire d'attaques par débordement de tampon. Les attaques par débordement de tampon remontent à 1988 at au désastreux incident connu sous le nom de "Robert Morris Worm Incident". Des informations précises et utilisables concernant cette attaque sont néanmoins restées rares jusqu'en 1996.

Une situation de débordement de tampon se produit lorsqu'un utilisateur ou un processus cherche à placer plus de données dans un tampon (ou une matrice fixe) qu'il n'y a de place attribuée au départ. Ce type de comportement est associé à des fonctions C spécifiques comme strcpy(), strcat() et sprintf() entre autres. Une situation de débordement de tampon provoque en principe une violation de segmentation. Elle ne peut néanmoins être exploité pour obtenir l'accès au système cible. Bien que nous traitons sur cette page des attaques par débordement de tampon, les situations de débordement de tampon peuvent également se produire via des programmes locaux.

Pour comprendre comment fonctionne un débordement de tampon, voici un exemple très simple :

Nous avons un tampon de longueur fixe de 128 octets. Supposons que ce tampon définisse la quantité de données qui peut être enregistrée comme entrée pour la commande VRFY de sendmail. Supposons également que sendmail soit une racine SUID et possède des droits racine, hypothèse qui peuvent ne pas être vérifiées sur tout système. Que se passe-t-il si des pirates se connectent au démon sendmail et envoient un bloc de données composé de mille "a" à la commande VRFY au lieu d'un nom d'utilisateur court ?

echo  "vrfy 'perl -e 'print "a" x 1000 ' ' " | nc www.Front_Nationnal.com 25

Le tampon VRFY déborde puisqu'il a été conçu pour ne contenir que 128 octets. Bourrer 1000 octets dans le tampon VRFY provoque un refus de service et bloque le démon sendmail ; il serait néanmoins encore plus dangereux de laisser le système cible exécuter le code de votre choix. Voici précisément comment fonctionne une attque réussie de débordement de tampon.

Au lieu d'envoyer mille lettres "a" à la commande VRFY, les pirates envoient du code spécifique qui provoque le débordement du tampon et exécute la commande /bin/sh. Souvenez vous que sendmail est exécuté à la racine. Donc, lorsque /bin/sh est exécuté, les pirates ont immédiatement un accès racine. Vous vous demandez peut être comment sendmail s'y est pris pour savoir que les pirates voulaient exécuter /bin/sh. La réponse est simple. Lorsqu'une attaque est exécutée, un code assembleur spécial connu sous le nom "d'oeuf" est envoyé à la commande VRFY comme partie de la chaîne effectivement utilisée pour faire déborder le tampon. Lorsque le tampon VRFY est en situation de débordement, les pirates peuvent régler l'adresse de retour de la fonction irrégulière de façon à modifier le flux du programme. Au lieu de permettre à la fonction de revenir à son emplacement mémoire propre, les pirates éxecutent le code assembleur dangereux qui a été envoyé au sein des données de débordement de tampon et qui va exécuter /bin/sh avec des droit racine.
Bingo !

Il faut à tout prix se souvenir que le code assembleur dépend de l'architecture et du système d'exploitation. Un débordement de tampon sur Solaris X86 est totalement différent de celui effectué sur Solaris SPARC. Le listing suivant vous montre à quoi ressemble un oeuf, ou un code assembleur, spécifique à Linux X86.

char shellcode [] =
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46
\x0c\xb0\x0b"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89
\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff/bin/sh";

Tout le monde peut aisément comprendre que des attaques par débordement de tampon soient extrêment dangereuses et aient donné lieu à un grand nombre de ruptures de sécurité. Notre exemple est très simpliste car il est très difficle à créer un oeuf qui fonctionne. Toutefois, la plupart des oeufs liés à un système ont déja été créés et sont disponibles sur le web. Le processus de création d'oeuf dépasse les ambitions de cette article. Nous vous invitons donc à vous reporter à l'article d'AlephOne dans Phrack Magazine (49) consultavble sur :
http://www.2600.net/phrack/p49-14.html

Parades

La meilleure parade au débordement de tampon est d'appliquer des méthodes de programmation sûres. Bien qu'il soit possible de concevoir et de coder un programme totalement exempt de bogues, il existe des mesures qui permettent de réduire les conditions de débordement de tampon. Voici quelques conseils à suivre :

• Concevoir le programme en ayant dès le départ des principes de sécurité à l'esprit. Trop souvent, les programmes sont codés à la hate dans le but de serspecter les délais d'un gestionnaire de projet quelconque. La sécurité est le dernier élément traité et passe généralement aux oubliettes.

• Envisager l'utilisation de compilateurs sûr tels que StackGuard d'Immunix (http://www.cse.ogi.edu/DISC/projects/immunix)

• Les arguments doivent être validés lorsqu'ils sont reçus par un utilisateur ou un programme.

• Utiliser des sous-programmes sûrs tel que fget(), strncpy() et strnact() et vérifier les codes de retour des apllets système.

• Minimiser l'utilisation des programmes racine SUID.

Il est également important de tester et vérifier chaque programme. Bien souvent, les programmeurs n'ont pas pas conscience d'une situation de débordement de tampon potentielle. Un tiers, en revanche, peut aisément détecter de telles défaillances. L'un des meilleurs exemple de test et de vérification de code UNIX est le projet OpenBSD géré par Théo de Raadt. Le groupe OpenBSD vérifie en permanence le code source d'UNIX et a réparé des entaines de situations de débordement de tampon sans parler d'autres types de problèmes de sécurité. C'est ce type de vérification approfondie qui a donnée à OpenBSD la réputation d'être l'une des version gartuite les plus sûres d'Unix.

Il est également possible de désactiver les services inutilisés ou dangereux. Aucun intrus ne peut pénétrer un service qui n'est pas activé. De plus, il est fortement recommandé d'utiliser TCP Wrappers (enveloppes TCP) (tcpd) et xinetd pour appliquer de manière sélective une liste de contrôle d'accès par service avec des fonctions d'ouverture de session améliorées. Tous les services ne peuvent etre enveloppés, mais ceux qui le sont augmentent singulièrement le niveau de sécurité de votre système.