Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
"Nous faisons simplement ce que cve.org veut que nous fassions", a répété à plusieurs reprises Greg K-H lors d'une récente présentation. une présentation récente. Au début de l'année, le nouveau statut CNA (CVE Numbering Authority) de l'équipe Kernel a surpris beaucoup de monde dans le domaine de la sécurité. Non seulement la position précédente était complètement opposée au système CVE - "Brûlez-les !" était une solution proposée - mais ils utilisaient une approche différente pour suivre les vulnérabilités (commit ids) et ne les rendaient pas publiques en tant que failles de sécurité en premier lieu.
La modification de l'ANC a eu un effet d'entraînement sur l'ensemble du secteur, pour des raisons qui deviennent de plus en plus évidentes : non seulement les CVE sont plus nombreux, mais leur nombre élevé rend le suivi, l'analyse et l'identification des CVE les plus importants beaucoup plus difficiles.
Mais tout cela a déjà été discuté précédemment par nous (et par de nombreux d'autres acteurs du secteur). Il y a même un rapport que nous avons publié il y a quelques moissi vous le souhaitez.
Ce qui est intéressant, c'est le point de vue de l'équipe Kernel elle-même sur cette question et, dans cet article, nous allons disséquer la dernière présentation et identifier le problème qui a été éludé lors de cette présentation.
Le texte cité ci-dessous est extrait de la présentation "Les CVE sont en vie, mais ne paniquez pas ! par Greg K-H, en conservant autant que possible le contexte.
L'éléphant dans la pièce
Commençons par quelques chiffres. Ceux-ci sont fournis explicitement dans la présentation. L'ANC du noyau émet actuellement (à partir d'octobre 2024) une moyenne de 55 nouvelles CVEs par semaine. Ce chiffre est légèrement inférieur aux 60 par semaine enregistrés au cours des premiers mois d'activité de l'ANC. Cependant, au cours des années précédentes, il y avait, selon la présentation, environ 20 CVEs par trimestre.
La politique initiale proposée par l'ANC du noyau a été interprétée comme une approche "tous les bogues reçoivent un certificat". Cette politique a été élargie : seuls 20 % des bogues en obtiennent un, ce qui nous donne 55 bogues par semaine. "C'est beaucoup. En suivant la liste de diffusion du noyau Linux, on a l'impression que c'est à peu près ce qu'il faut.
Le processus est le suivant : pour chaque livraison stable, il y a (au moins) trois personnes qui l'examinent et décident si elle mérite un CVE ou non. En l'absence de consensus, la question est débattue publiquement. Si un tel consensus est atteint, un CVE est attribué.
Lorsqu'un CVE est attribué à un bogue particulier, il peut encore être révoqué après coup si des arguments convaincants sont présentés. Cela représente 1 à 2 % des CVE attribués.
L'ANC du noyau n'est "pas le premier".
...sauf que c'est le cas. En raison des (très grands) chiffres en jeu, et évidemment pour répondre aux critiques, la présentation comprend une liste d'autres projets et le nombre de CVE hebdomadaires qu'ils génèrent. WordPress, avec 112 par semaine, est en tête - avec la réserve qu'il ne s'agit pas vraiment de wordpress, puisqu'il inclut tous les plugins et les thèmes, ce qui fait qu'il ne s'agit pas vraiment de 112 par semaine. MITRE affiche 95 par semaine, mais il ne s'agit pas non plus d'un seul projet. Windows (11-12), Chrome (6), macOS (6), iOS (2-3) figurent également sur la liste. Le fait que le noyau accumule plus de CVE que n'importe quel autre projet individuel, et plus que tous les systèmes d'exploitation concurrents réunis, pourrait en dire plus sur les problèmes éventuels liés au processus que sur le noyau lui-même.
Pourquoi cela s'est-il produit ?
La raison invoquée pour commencer à publier des CVE était double : premièrement, cve.org permettait désormais aux projets open-source d'avoir leur propre CNA et, deuxièmement, il existe des lois et des réglementations qui exigent la divulgation des vulnérabilités dans les différentes juridictions (avec des d'autres suivront).
"Nous sommes tenus de le faire" [en référence à l'émission de CVE], donc ce n'est pas comme si le génie proverbial pouvait être remis dans la bouteille.
Qu'est-ce qu'une vulnérabilité ?
L'une des principales différences entre l'ANC du noyau et les ANC d'autres projets est, comme nous l'avons mentionné, le grand nombre de CVE émis. Cela se résume à l'interprétation de la définition de CVE par cve.org. Selon l'équipe du noyau, les bogues suivants nécessitent la création d'un nouveau CVE (extrait de la présentation) :
- "Tout crash ou redémarrage déclenché par l'utilisateur
- Utilisation de la mémoire après coup / fuite / débordement
- Contrôles de limites incorrects
- Refus de service
- Erreurs de logique
- Beaucoup d'autres choses"
Les éléments suivants ne sont PAS considérés comme des vulnérabilités et n'obtiendront pas de CVE :
- "Corruption/perte de données
- Problèmes de performance
- Corrections de bogues qui ne sont pas déclenchées de l'extérieur
- Pas de CVE matériel"
En particulier, le premier point de la deuxième liste, la corruption des données, mérite une explication plus longue au cours de la présentation et, très franchement, ne pas considérer les bogues de perte de données potentielle comme des problèmes de sécurité, c'est ignorer les attaques par déni de service potentielles qui y sont associées (comme l'a fait remarquer à juste titre un membre de l'auditoire au cours des questions et réponses). La raison ? "Nous suivons les directives de cve.org. C'est leur problème, pas le nôtre". Ce n'est pas une position très utile.
"Bonne chance pour résoudre ce problème".
Le grand problème des distributions d'entreprise
Des représentants de différents fournisseurs de services de distribution ont assisté à la présentation et, au cours des questions-réponses, ils ont clairement exprimé leur point de vue sur la question : ils n'étaient pas satisfaits, c'est le moins que l'on puisse dire.
Le raisonnement est le suivant : si vous consommez le noyau et l'intégrez dans votre environnement, vous (devriez) avoir une bonne compréhension de ce que vous utilisez, et il serait donc moins pénible d'identifier les CVE qui sont réellement significatifs pour votre environnement particulier - vous n'avez pas besoin de vous préoccuper du code qui n'est jamais utilisé ou chargé - de sorte qu'une partie considérable des 55 CVE par semaine n'a pas vraiment d'importance dans chaque cas particulier.
Cependant, les vendeurs de distributions sont dans une position plus proche de l'équipe du noyau que des utilisateurs finaux. Une distribution peut être utilisée d'une infinité de façons et de situations différentes et, tout comme l'équipe du noyau, le vendeur ne peut prétendre savoir quelles parties du noyau seront pertinentes ou non. Par conséquent, il doit s'attaquer à toutes les vulnérabilités qui se présentent à lui. Cela se répercute en aval sur les entreprises qui travaillent sur les versions du fournisseur de distribution.
Chacune de ces 55 CVE doit donc être analysée, notée, corrigée, testée et mise à la disposition des entreprises clientes. Si vous cherchiez une raison pour laquelle les bulletins de sécurité des fournisseurs comprennent aujourd'hui des centaines de CVE, c'est parce qu'ils sont regroupés toutes les quelques semaines.
Pourtant, il suffirait de transposer les corrections d'amont en aval et de s'arrêter là, n'est-ce pas ? Mais ce n'est pas tout.
Les CVE attribués par l'ANC du noyau ne font référence qu'au commit du correctif proprement dit. S'il existe toute une chaîne d'autres correctifs nécessaires pour que le correctif s'applique ou fonctionne correctement, c'est un exercice que nous laissons au lecteur.
Ils ne sont pas non plus "testés indépendamment, mais seulement en bloc". Cela devient inutile dès qu'une distribution applique une quelconque personnalisation, car tous les tests doivent alors être répétés.
"Les distros d'entreprise ont un problème, qu'elles se sont infligées elles-mêmes, et je n'ai aucune sympathie pour elles" [il s'agit des corrections rétroportées sur les anciennes versions du noyau qui sont livrées et prises en charge par les vendeurs de distributions]. En effet.
"Ce n'est pas mon problème."
L'utilisateur final/l'organisation
"Vous devez mettre à jour le noyau le plus récent et redémarrer, ou trier tous les correctifs, appliquer ceux qui sont pertinents et redémarrer. Vous pouvez utiliser le live patching". Dans le même temps, il reconnaît que beaucoup ne peuvent pas le faire, car leur infrastructure ne peut pas supporter le nombre de redémarrages. Il faut donc trier 55 CVE par semaine, chaque semaine, ou prendre la dernière version. Il s'agit d'un choix à la Pyrrhus qui s'avère extrêmement coûteux dans un environnement d'entreprise.
La troisième et, tout compte fait, la seule solution possible consiste à d'appliquer des correctifs en direct sur vos systèmes.
L'état des choses
"Nous faisons exactement ce que cve.org nous a demandé de faire" semble être la position par défaut pour défendre le processus actuel. Accepter cela au pied de la lettre et dire que "nous ne provoquons pas de déni de service" [sur le processus CVE] n'est pas non plus l'intention. Mais la situation réelle à laquelle sont confrontées de nombreuses entreprises, fournisseurs de distribution et sociétés de cybersécurité, ainsi que les problèmes de conformité et de sécurité qui découlent du fait que les systèmes sont signalés pour 55 nouvelles vulnérabilités chaque semaine, n'aident pas vraiment à accepter la situation actuelle comme autre chose qu'une conformité malveillante (intentionnelle ou accidentelle).
L'énorme travail réalisé par l'équipe Kernel, et en particulier par la petite équipe Kernel CNA, méritait mieux, mais il a malheureusement causé trop de peine et de souffrance à des milliers de professionnels de la sécurité dont l'écosystème entier est maintenant inondé de nouveaux problèmes, souvent non notés, que cela n'a fait qu'ajouter un fardeau supplémentaire à un environnement déjà stressant.
"Cela provoque des remous et des heurts dans l'écosystème. Je sais que je vais être cité à ce sujet". Je ne plaisante pas.
Note : Merci à Greg K-H pour la transparence du processus et pour avoir jeté un coup d'œil derrière le rideau.
