Sorry, you need to enable JavaScript to visit this website.

Image CAPTCHA
Saisir les caractères affichés dans l'image.

Faille

Faille
2009-05-252013-02-11sécurité applicativefr
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...
Publié le 25 Mai 2009 par Philippe Maltere dans sécurité applicative
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).

8 Commentaires

  • 8 Juin 2009
    2009-06-08
    par
    Florent
    En effet j'ai une lacune au niveau du tas. Il s'agit en fait d'une liste doublement chaînée avec réallocation des espaces libérés. C'est beaucoup plus complexe que je ne l'imaginais. Du coup j'ai trouvé un texte intéressant sur le sujet.

    Le coup des BOF c'est has been c'est pour montrer qu'il y a deux écoles (si ce n'est plus). Disons que c'est plutôt old school (même si je risque encore de me faire critiquer :).
  • 8 Juin 2009
    2009-06-08
    par
    Tout à fait d'accord.

    Cela fait d'ailleurs une excellent conclusion.
  • 8 Juin 2009
    2009-06-08
    par
    Je ne suis pas sûr du côté has been du buffer overflow.

    Le sql injection on peut le contrôler un peu plus facilement
  • 8 Juin 2009
    2009-06-08
    par
    C'est aussi pour cela, que je préfère traduire heap par file(c'est une file particulière).

    Pour moi, pile = LIFO et file = FIFO.

    pour le reste, je suis tout à fait d'accord avec toi.
  • 27 Mai 2009
    2009-06-08
    par
    Mrtrankill
    Un point souvent oublié sur la présence de failles dans le développement d'applications
    (que ce soit pour les buffers, les stacks et autres overflow, comme pour les injections SQL et autres XSS) est la pression "économique" sur le développement.

    Tant que la gestion de projet n'intègre pas de Q&A sécurité (en terme de budget,planning, ressource etc...) il n'y aura pas de progrès.
    Tant que le commanditaire (interne ou en sous-traitance) n'intègre pas de volet sécurité, il n'y aura pas de progrès

    On retrouve trop souvent ces erreurs dans les projets gagnés sur appel d'offre, les cycles courts etc...

    Il est sincèrement pas trivial de coder proprement et de rentrer dans les temps projets.

    Il ne faut pas remettre en question uniquement les méthodes des développeurs mais c'est toute la chaine de création d'une application qui doit intégrer un volet sécurité.

    pour faire bref et marketing ;)

    La sécurité c'est l'affaire de tous

Pages

Ajouter un commentaire

comments

  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <br>

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Email HTML

  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
Image CAPTCHA
Saisir les caractères affichés dans l'image.
Changer d'affichage