Conduire un audit

Cette page donne une vue d'ensemble sommaire des étapes nécessaires pour conduire un audit de paquet.

La première étape est en fait celle du choix du paquet à examiner, vous devriez choisir le plus critique en terme de sécurité.

Allez voir la liste des paquets que nous considérons comme importants à auditer pour des suggestions pour vous aider à vous décider.

Il doit être clair que nous n'essayons pas de nous assurer qu'un paquet n'est audité qu'une seule fois. Si plusieurs personnes choisissent d'examiner le même paquet, c'est une bonne chose, puisque cela démontre que de nombreuses personnes considèrent le paquet comme sensible en terme de sécurité.

En autorisant une sélection des paquets essentiellement aléatoire, nous simplifions la coordination et éliminons le problème du comment pouvez-vous faire confiance à la personne X pour faire un bon travail ? (nous n'en avons pas besoin puisqu'on suppose que tôt ou tard, quelqu'un d'autre examinera le même programme).

Démarrer l'audit

Après avoir fait votre sélection de paquet, vous aurez à démarrer véritablement l'audit.

Si vous n'êtes pas sûr des types de problèmes que vous cherchez, commencez par lire un livre sur le développement de logiciels sûrs.

Le guide Secure Programming for Linux and Unix HOWTO comporte beaucoup de bonnes informations qui peuvent vous aider. Secure Coding: Principles & Practices par Mark G. Graff et Kenneth R. van Wyk est également un excellent livre.

Bien que les outils ne soient par parfaits, ils restent cependant très utiles pour trouver des vulnérabilités. Allez voir la page des outils d'audit pour plus d'informations sur certains outils d'audit et leur utilisation.

De la même façon que regarder le code en lui-même, c'est une bonne idée de lire la documentation du paquet, d'essayer de l'installer et de l'utiliser.

Cela doit vous permettre de penser à des moyens de déstabiliser le programme dans ses opérations habituelles.

Rapporter les problèmes

Si vous découvrez un problème dans le paquet que vous examinez, vous devriez le rapporter. Dans le rapport d'un bogue de sécurité, essayez de fournir un correctif ; ainsi, les développeurs pourront le corriger dans les temps. Il n'est pas nécessaire de fournir un exemple d'attaque (souvent appelé exploit ou proof of concept) puisque le correctif devrait parler de lui-même. C'est souvent mieux d'investir son temps dans la réalisation d'un correctif propre plutôt que dans la fourniture d'une attaque réussissant à exploiter le bogue.

Voici une liste des étapes que nous vous recommandons de suivre si vous avez trouvé un bogue de sécurité dans Debian :

  1. Essayez de produire un correctif au bogue ou de rassembler assez d'informations pour que d'autres personnes puissent déterminer l'existence du bogue. Idéalement, chaque rapport devrait contenir un correctif du problème découvert, qui a été testé et confirmé comme réglant vraiment le problème.

    Si vous n'avez pas de correctif, plus vous donnerez de détails sur l'étendue du problème, sa gravité et les manières de le contourner, mieux ce sera.

  2. Tout d'abord, regardez si le bogue de sécurité est présent dans l'actuelle distribution stable de Debian, s'il peut être présent dans d'autres distributions, ou dans la version fournie par les développeurs amont.
  3. En se basant sur la vérification précédente, rapportez le problème :
    • aux responsables amont à travers l'adresse électronique de contact sur la sécurité, en fournissant l'analyse et le correctif ;
    • à l'équipe de sécurité de Debian si le bogue est présent dans une version officielle de Debian. Typiquement, l'équipe de sécurité de Debian assignera une référence CVE à la vulnérabilité. L'équipe de sécurité se coordonnera avec toutes les autres distributions Linux si nécessaire, et contactera le responsable de paquet de votre part. Vous pouvez cependant envoyer une copie du courrier électronique également au responsable de paquet. Procédez ainsi uniquement lors de vulnérabilités à faible risque (voir ci-dessous) ;
    • si le bogue n'est pas présent dans une version officielle de Debian, et que l'application peut être dans d'autres distributions ou systèmes d'exploitation, envoyez alors un courrier électronique à vendor-sec (une liste de diffusion privée que la plupart des distributions de logiciels libres utilisent pour discuter de bogues de sécurité). Vous n'avez pas besoin de le faire si vous avez déjà averti l'équipe de sécurité de Debian du bogue, puisqu'ils le feront suivre à cette liste ;
    • si le bogue n'est présent dans aucune version officielle de Debian, et que vous êtes absolument sûr que l'application n'est pas présente dans d'autres distributions ou systèmes d'exploitations, alors rapportez-le par le système de suivi des bogues.
  4. Une fois la vulnérabilité publique (i.e. que l'équipe de sécurité de Debian ou un autre vendeur a publié une annonce), le bogue ainsi que toutes les informations pertinentes devront être enregistrés dans le système de suivi des bogues de Debian, pour garder la trace du problème de sécurité des versions non officielles de Debian (i.e. Sid ou Testing). Ceci est généralement effectué par l'équipe de sécurité elle-même ; si vous vous apercevez que cela a été oublié, ou que vous n'avez pas rapporté le bogue à l'équipe de sécurité, vous pouvez rapporter vous-même le bogue. Assurez-vous que vous avez correctement marqué le bogue (utilisez l'étiquette security) et que vous avez fixé la bonne gravité (généralement grave ou plus haute). Assurez-vous aussi que le titre du bogue contienne la bonne référence CVE s'il en a été attribué une. Cela fournit un moyen de garder la trace des bogues de sécurité afin qu'ils soient corrigés à la fois dans les versions officielles et non officielles de Debian.
  5. Si vous le souhaitez, une fois que la vulnérabilité est publiée, vous pouvez transmettre l'information à des listes de diffusion publiques, comme full-disclosure ou Bugtraq.

Vous remarquerez que ces étapes peuvent dépendre du risque associé à la vulnérabilité trouvée. Vous devez évaluer le risque en vous basant sur :

Ce n'est pas la même chose de rapporter, par exemple, une attaque locale par lien symbolique qui ne peut être utilisée que par des utilisateurs authentifiés, qui leur permet uniquement d'endommager le système, que de rapporter une exploitation distante de dépassement de tampon, qui donne les droits administrateur, et est présente dans un logiciel d'usage très répandu.

Dans la plupart des cas, puisque la plupart des bogues de sécurité ne devraient pas être fermés avant qu'ils soient corrigés, ne les rapportez pas par l'habituel système de suivi des bogues de Debian, mais rapportez plutôt le problème directement à l'équipe de sécurité qui s'occupera de publier un paquet mis à jour, et une fois la correction effectuée, de le rapporter dans le BTS.