La sécurité en contexte : quand un CVE n’est-il pas un CVE ?

Chez Snyk, nous nous appuyons sur quelques principes généraux pour guider notre réflexion et nos décisions en matière de sécurité.

Tout d’abord, il est essentiel de comprendre contre qui nous nous protégeons, car cela détermine la manière dont nous devons agir. Par exemple, si notre artefact est un serveur web, nous devons le protéger contre les utilisateurs non fiables. En revanche, s’il s’agit d’un logiciel de chiffrement, nous devons évidemment le protéger même contre les personnes ayant un accès physique au système. Dans chacun de ces cas, nous définissons clairement la limite du risque et les points sur lesquels concentrer notre attention.

Deuxièmement, la configuration fait partie de votre base de code. Si un acteur malveillant a accès à votre configuration, c’est fondamentalement comme s’il avait accès à votre base de code.

Face au tsunami de systèmes vulnérables provoqué par la récente vulnérabilité Log4j 2.x (Log4Shell), on peut comprendre que la communauté recherche avec toujours plus d’attention d’autres vulnérabilités potentielles. Mais nous devrions peut-être aussi profiter de cette occasion pour faire une pause et réfléchir avant de porter un jugement hâtif sur chaque problème de sécurité potentiel découvert dans notre code. Gardons la tête froide : tout ce qui pose un problème de sécurité ne mérite pas nécessairement le même traitement.

À titre d’exemple, examinons sous cet angle l’attribution récente de CVE-2021-4104 à Log4j 1.x. Pour exploiter cette faille, il faudrait avoir un accès direct aux fichiers de configuration afin d’en modifier les paramètres. Des discussions similaires émergent actuellement autour du projet Logback, ainsi que dans la communauté Node.

Soyons clairs : mettre au jour des vulnérabilités potentielles est toujours une bonne chose. Mais dans un climat de panique médiatique, il est également important de faire preuve de discernement et de redéfinir les priorités de notre communauté. Déclencher un nouveau tsunami de vulnérabilités potentielles peut faire plus de mal que de bien : cela surcharge davantage des équipes de sécurité déjà sous pression et brouille les pistes, au détriment des efforts déployés par le secteur pour sécuriser les logiciels open source.

Réfléchir aux CVE avec discernement

Les discussions évoquées dans les fils ci-dessus soulèvent des questions très intéressantes.

Par exemple, si l’exploitation d’une vulnérabilité nécessite un accès privilégié aux fichiers d’un système, s’agit-il vraiment d’une vulnérabilité ? On peut configurer presque n’importe quel logiciel moderne un tant soit peu complexe pour qu’il fonctionne de manière non sécurisée. On pourrait comparer cela au fait qu’il est tout à fait possible de configurer sshd pour autoriser les connexions avec un mot de passe vide. Devrait-on considérer cela comme une nouvelle vulnérabilité dans sshd ?

L’une des méthodes utilisées par notre équipe de sécurité consiste à examiner la différence entre les comportements attendus et inattendus. Si un logiciel peut être configuré pour exécuter du code à distance et que cette fonctionnalité est bien documentée, constitue-t-elle une faiblesse exploitable ? On peut faire valoir qu’il s’agit d’un comportement attendu, et non, à proprement parler, d’une vulnérabilité de sécurité.

Devrait-on concevoir des logiciels qui ne proposent aucun mode configurable non sécurisé ? L’objectif peut sembler louable, mais il est quelque peu en contradiction avec notre façon de concevoir les logiciels open source depuis au moins 30 ans. Les logiciels open source ont généralement été conçus pour offrir un maximum de possibilités de configuration et couvrir tous les cas d’usage. Ces dernières années, les paramètres sécurisés par défaut sont devenus un objectif secondaire, mais le principe a toujours été de donner aux utilisateurs la liberté de configurer les logiciels comme ils l’entendent, de manière sécurisée ou non.

Aujourd’hui, les CVE sont faciles à déclarer, aussi bien par des particuliers que par des entreprises, et elles ont de la valeur en raison de la crédibilité et du prestige qui leur sont associés. Cette combinaison particulière peut vraisemblablement conduire à des attributions discutables. D’un autre côté, pouvoir signaler facilement des problèmes de sécurité potentiels est forcément une bonne chose : nous sommes donc face à un certain paradoxe.

En tant que secteur, nous identifions les vulnérabilités de mieux en mieux, tout en créant beaucoup plus de logiciels. Il est donc facile de comprendre le risque de saturation. 

Identifier correctement les vulnérabilités logicielles, les évaluer et proposer des mesures d’atténuation mobilise énormément de ressources et repose principalement sur un travail manuel, en particulier dans les cas complexes. Les approches d’apprentissage automatique gagnent en utilité et l’IA pourrait s’avérer encore plus précieuse, mais, dans bien des cas, les ordinateurs ne nous aident pas beaucoup à établir un diagnostic — ce qui est ironique.

Note de la rédaction (19 déc. 2021) : Depuis la publication de cet article, le projet Logback a attribué le CVE-2021-42550 au problème évoqué ci-dessus. Au vu des arguments exposés dans cet article, Snyk ne va pas publier d’avis de sécurité concernant ce problème pour le moment. Nous continuerons à échanger avec la communauté Logback et espérons qu’une discussion ouverte permettra d’aboutir à un consensus.

Et maintenant ?

Les points de discussion présentés ici ne visent pas à modifier un CVE en particulier, mais plutôt à ouvrir le débat sur l’avenir de l’évaluation des vulnérabilités et sur ce que nous considérons aujourd’hui, et à l’avenir, comme des failles de sécurité. Concevoir des logiciels open source puissants et polyvalents, adaptés à des cas d’usage généraux, implique inévitablement de proposer des modes configurables offrant différents niveaux de sécurité. Si nous voulons continuer dans cette voie, les utilisateurs ont également la responsabilité de connaître les risques liés à ces choix. La solution réside peut-être autant dans une meilleure documentation et davantage de sensibilisation que dans la classification des vulnérabilités potentielles pour des cas d’usage normaux.

Nous aimerions connaître l’avis de la communauté. Contactez-nous sur les réseaux sociaux (@snyksec) pour en discuter.