Il est parfois difficile de trouver un bon sujet d'article, je peux y passer des heures. Je pensais en voir trouvé un excellent, le sujet était « La vie des chiens chez les Inuits ». Mais on m'a dit, que le sujet était un peu trop polémique, et pas assez fédérateur. Qu'à cela ne tienne, un nouveau brainstorming avec moi-même. Puis... Bon dieu, mais c'est bien sûr...
L'Idée, le Sujet sans qui la sécurité informatique ne serait pas vraiment ce qu'elle est. LA vulnérabilité, LA faille... en deux mots, Buffer Overflow (ou dans la langue de Victor Hugo, le dépassement de tampon). « Bue feur oh vert flot, kezako ? ». Pas d'insultes, s'il vous plait... Ce n'est pas un bon sujet ? Tout logiciel passé ou à venir aura au moins une vulnérabilité de type buffer overflow, ceci est un axiome qui peut même se démontrer (c'est dire) vu la complexité grandissante des logiciels. Ceci est la conséquence directe de la non validation de la longueurs des tampons mémoires ou de la non vérification des données copiées dans ce tampon.

Un exemple simple
Char buf [100] ;
...
Buf [101] = 'dommage' ;

Dans ce cas, tout à fait correct pour le compilateur d'un point de vue syntaxe, on crée un débordement sur... on ne sait pas, une partie de la mémoire, qui peut entrainer un plantage du programme, et une possibilité (ceci est à définir) de prendre le contrôle de la machine entière. Pourtant, ce type d'erreur pourrait être aisée à annihiler, il est « facile » de contrôler les variables, il suffit d'avoir les bonnes pratiques de programmation. Plus « facile » à dire qu'à faire à en croire la pratique et la réalité.

Afin de mieux comprendre pourquoi ce dépassement peut être un problème, il faut se rappeler comment un système d'exploitation gère sa mémoire. Chaque programme a besoin de mémoire pour fonctionner, et en gros la mémoire est divisé en trois parties :

• La mémoire fixée pour le programme qui contient le code lui-même, des données statiques
• La file (heap) qui est utilisée pour stocker les données dynamiques
• La pile utilisée pour passer des variables aux fonctions ou à d'autres programmes

Seulement voilà les deux dernières parties sont gérées dynamiquement, la file s'étend en commençant par les adresses basses, la pile fait exactement le contraire. Et ce qui peut arriver arrive, si l'on passe un argument trop gros à la pile, il sera traité, et ira donc dans la file, et débordera sur la mémoire allouée à la pile, dans ce cas, le pointeur de pile est modifié, donc l'adresse de retour est modifiée, donc fini le programme... L'attaque la plus simple se rapproche donc d'un deni de service du programme. Mais elle peut être plus ambitieuse, on peut positionner dans la pile une adresse de retour correspondant au petit programme malicieux qui permettra de prendre le contrôle. Je ne m'appesantirai pas sur la façon de faire, il existe sur Internet une littérature abondante sur ce sujet, par exemple « Smash the Stack for Fun and Profit que vous trouverez sur http://www.phrack.org) .

Il existe bien des méthodes à postériori pour essayer d'éviter cette plaie, comme des audits de code par exemple, ou une meilleure protection des systèmes grâce à des HIPS. Mais, il faut le répéter ce ne seront que des rustines, la seule méthode fiable est de sensibiliser à la sécurité les programmeurs, c'est-à-dire à l'amont de tout projet de développement. Afin qu'ils puissent contrôler tous les types d'entrée de variables du programme (soit par saisie directe, soit par passage de paramètre à la pile).