432 failles corrigées dans le noyau Linux ? Pas si vite
La publication en 48 heures de 432 bulletins CVE pour le noyau Linux a provoqué des interrogations sur la meilleure manière d’intégrer un tel flot de corrections dans les environnements de production. La situation est plus complexe qu’il n’y paraît.
Entre le 20 et le 21 juillet, le noyau Linux a vu la publication de 432 identifiants CVE (Common Vulnerabilities and Exposures), des étiquettes attribuées aux failles de sécurité. Cependant, ces chiffres ne signifient pas que 432 failles critiques ont été découvertes et corrigées en deux jours. Dans le cas du noyau Linux, les CVE sont attribués après la correction des bugs, contrairement à la plupart des logiciels. Cela s’explique par le fait que le projet Linux est devenu sa propre autorité de numérotation des CVE depuis février 2024, avec des règles spécifiques. Les failles non corrigées n’ont donc pas de CVE dans ce contexte. Les 432 CVE correspondent ainsi à des correctifs déjà intégrés dans la branche principale du noyau, mais leur publication massive en peu de temps a suscité des interrogations sur leur gestion en production.
Un CVE classique est attribué à une faille de sécurité avant que le correctif ne soit disponible, souvent pour alerter les utilisateurs. Il est accompagné d’un score CVSS (Common Vulnerability Scoring System) qui évalue son niveau de dangerosité, ainsi que de détails techniques comme le vecteur d’attaque ou les privilèges nécessaires. En revanche, dans le cas du noyau Linux, les CVE sont attribués après la correction du bug, et aucun score CVSS n’est calculé. Les développeurs du noyau ne connaissent pas l’usage qui sera fait de Linux, ce qui rend impossible une évaluation précise du risque. De plus, un CVE Linux correspond directement à un identifiant de commit Git, c’est-à-dire une modification précise du code source. Cette méthode explique pourquoi l’utilisation d’outils automatisés comme les fuzzers (logiciels testant les vulnérabilités) ou les analyses statiques génère des pics de CVE.
Le volume élevé de CVE publiés pour le noyau Linux s’explique par plusieurs facteurs. D’abord, l’équipe du noyau attribue systématiquement un CVE à tout correctif de bug susceptible d’impacter la stabilité ou l’accès mémoire, même si le bug n’est pas exploitable en pratique. Ensuite, l’utilisation croissante d’outils automatisés comme les fuzzers ou les analyses statiques permet de détecter des milliers de bugs mineurs ou de cas limites, qui sont ensuite corrigés et reçoivent un CVE. Enfin, depuis février 2024, le projet Linux est sa propre autorité de numérotation, ce qui a pu faciliter l’attribution massive de CVE. Greg Kroah-Hartman, mainteneur principal des branches stables du noyau, a expliqué que ces CVE étaient en préparation depuis des semaines, et que leur publication soudaine ne devrait surprendre personne.
La publication de 432 CVE en 48 heures a soulevé un problème concret pour les entreprises : comment gérer un tel flux de corrections dans leurs environnements de production ? Jan Schaumann, architecte en chef de la sécurité chez Akamai Technologies, a exprimé son inquiétude sur la liste de diffusion OSS-SEC, soulignant que les organisations peinent à suivre ce rythme. En effet, les environnements de production utilisent souvent des versions modifiées ou anciennes du noyau, où les équipes doivent rétroporter (backporter) manuellement les corrections qui les intéressent. Avec 432 CVE, il devient difficile de déterminer quelles corrections sont prioritaires et doivent être appliquées. Schaumann a évoqué la possibilité d’utiliser des LLM (Large Language Models) pour automatiser ce processus, mais reconnaît que cette solution est complexe à mettre en œuvre pour de nombreuses organisations.
Face à ce défi, Greg Kroah-Hartman, mainteneur du noyau Linux, recommande une solution simple : toujours utiliser la dernière version stable disponible sur la branche souhaitée et vérifier régulièrement l’ensemble des systèmes gérés. Il admet que cette approche n’est pas toujours facile pour les entreprises, mais souligne que des outils payants existent pour gérer ce processus efficacement. À défaut, il conseille d’utiliser des distributions comme *Debian* ou *Yocto*, dont les pratiques de sécurité sont jugées exemplaires. Pour les organisations ne pouvant pas se permettre un pipeline automatisé, Kroah-Hartman suggère de vérifier manuellement les *CVE* en croisant les fichiers corrigés avec ceux réellement utilisés dans l’environnement. Il insiste sur le fait que les 432 *CVE* publiés ne représentent pas un problème en soi, mais plutôt une opportunité de renforcer la sécurité en appliquant les mises à jour disponibles.
