On recense chaque semaine de nouvelles vulnérabilités critiques qu’éditeurs et administrateurs système tentent par tous les moyens de corriger. Mais d’où proviennent toutes ces vulnérabilités ?

Une simple recherche dans la NVD (National Vulnerability Database), base de données américaine des vulnérabilités, révèle que plus de 3 300 nouvelles vulnérabilités ont été publiées au cours des trois derniers mois.1 Nombre d’entre elles sont rares et limitées à certaines applications spécialisées. Néanmoins, presque tous les deux mois, une faille de sécurité à grande échelle affectant des millions d’utilisateurs est détectée. La vulnérabilité Heartbleed2 avait ainsi affecté près de la moitié des serveurs web Internet.

Pourquoi autant de vulnérabilités et à une telle fréquence ? La raison est simple. Les vulnérabilités peuvent avoir trois causes principales : la qualité du code, la complexité et une trop grande confiance accordée aux données en entrée.

Qualité du code

C’est généralement la première raison qui est pointée du doigt. Mais pourquoi ? Programmation bâclée ? Pas nécessairement. Il s’agit le plus souvent d’un choix délibéré. Les équipes de développement accordent en général la priorité aux fonctionnalités pour lesquelles les clients paieront. Or, en dehors des professionnels de la sécurité, la plupart des gens ne sont pas prêts à dépenser pour la sécurité. Cependant, certains sont tout à fait disposés à mettre la main au porte-monnaie, mais cela concerne le plus souvent des applications et des systèmes qui ne sont pas aussi utiles ni flexibles que les solutions grand public. Il s’agit de produits moins sécurisés nécessitant un budget supplémentaire pour la sécurité.

Autre facteur influant sur la qualité du code : le concept de « produit minimum viable »,3 une stratégie visant à concevoir des produits qui possèdent juste ce qu’il faut de caractéristiques et de valeur pour séduire les clients. Les autres fonctionnalités sont jugées secondaires et peuvent être ajoutées ultérieurement. Le mot d’ordre se résume donc à : ne jamais construire un château quand une simple tente suffit. Le problème est que nous finissons par vivre dans une tente pendant des années. Nous savons aussi que corriger des programmes de sécurité a posteriori est une opération plus coûteuse, qui retarde par ailleurs l’ajout de fonctions de sécurité en réponse aux nouvelles demandes des clients (et du marché). Ce n’est souvent qu’après une série d’incidents que la sécurité est élevée au rang de priorité.4

Complexité

La plupart des applications modernes sont d’une telle complexité qu’elles dépassent l’entendement d’une seule personne. Pour l’utilisateur moyen, toute cette complexité est masquée par l’interface utilisateur et l’infrastructure sous-jacente, mais les professionnels de l’informatique savent ce qu’il en est. La version actuelle du navigateur Firefox, par exemple, comprend 16 millions de lignes de code qui ont été écrites par 5 094 développeurs sur une période de 10 ans.5

Si l’on considère tous les composants, les interdépendances, les couches, les bibliothèques, les modes d’interface et la rétrocompatibilité intégrés dans ces applications, la présence de failles de sécurité majeures n’a rien de surprenant.

Il est de notoriété publique que le fonctionnement de systèmes dynamiques et complexes est difficilement prévisible et peut avoir des résultats inattendus.6 Une chose est sûre cependant : les applications logicielles volumineuses et complexes contiennent inévitablement des bugs qui, pour certains, occasionneront des failles de sécurité.

Trop grande confiance accordée aux données en entrée

Si vous examinez la plupart des vulnérabilités, vous verrez qu’elles surviennent aux endroits du programme qui acceptent l’entrée de données. Par conséquent, chaque canal d’entrée de données dans le système constitue une surface d’attaque. Ces vulnérabilités exploitent les faiblesses des points d’entrée afin d’introduire de nouvelles commandes. Regardez d’où proviennent les attaques par débordement de tampon, injection SQL ou Cross-Site Scripting : du détournement des canaux d’entrée de données. Le problème ne date pas d’hier. Cela fait plusieurs décennies que les programmeurs connaissent son existence et sont formés à filtrer les données en entrée non conformes.7

Compte tenu de la complexité des logiciels et de la vitesse à laquelle ils sont développés, il n’est pas étonnant que les programmeurs ne disposent pas du temps ni des ressources nécessaires pour filtrer efficacement tous les flux d’entrée de données possibles.

Conjonction de plusieurs facteurs

Dans son essai How Complex Systems Fail, l’auteur, Richard I. Cook, constate que les pannes majeures résultent de petites défaillances bénignes qui se combinent pour créer un problème systémique.8 Tous ces problèmes se conjuguent et entraînent un phénomène chronique de vulnérabilités de sécurité qui se répand dans toute l’industrie du logiciel.

Que faire de ces constats ? Tout d’abord, vous pouvez tenir compte de ces principes pour estimer approximativement l’ampleur et la fréquence des vulnérabilités potentielles d’un système, ce qui vous aidera à évaluer les risques. Comme chaque chemin d’entrée de données représente un vecteur d’attaque possible, vous pouvez réduire le degré d’exposition de tous les éléments que vous souhaitez protéger. Si vous exposez un chemin d’entrée, veillez à le filtrer et à le surveiller. N’oubliez pas non plus que les outils de sécurité sont des logiciels. Il convient donc de mettre en place des moyens de défense et de procéder à des tests réguliers.