On recense chaque semaine de nouvelles vulnérabilités critiques que les éditeurs et les administrateurs système doivent corriger. Mais d’où proviennent toutes ces vulnérabilités ? Laurent Pétroque, expert fraude en ligne chez F5 Networks, répond. Les failles sont là pour durer car elles résultent de la manière de développer les logiciels qui n’est pas prête de changer.
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 3300 nouvelles vulnérabilités ont été publiées au cours des trois derniers mois. 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é affectant à grande échelle des millions d’utilisateurs est détectée. La vulnérabilité Heartbleed avait ainsi affecté près de la moitié des serveurs web Internet.
Trois causes naturelles aux failles de sécurité
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.
La qualité du code est généralement la première raison qui est pointée du doigt. Mais pourquoi ? S’agit-il d’une programmation bâclée ? Pas nécessairement. Il s’agit le plus souvent d’un choix délibéré de la part des équipes de développement. Celles-ci 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é.
Le MVP crée les conditions des failles sécuritaires
Autre facteur influant sur la qualité du code : le concept de « produit minimum viable » ou MVP (Minimum Viable Product), 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é.
Deuxième souci : la 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.
Le plat de spaghetti
La présence de failles de sécurité majeures n’a rien de surprenant quand 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.
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. 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é.
Enfin, il y a une 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 (buffer), 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 des décennies que les programmeurs connaissent son existence et sont formés à filtrer les données non conformes en entrée.
Petites causes grands effets
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 ni du temps ni des ressources nécessaires pour filtrer efficacement tous les flux d’entrée de données possibles.
La conjonction de plusieurs facteurs explique la situation actuelle. Dans son essai « How Complex Systems Fail », l’auteur, Richard 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. 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.
Bel article . L’exemple sur Firefox en dit long sur la complexité