Il y a le bon CVE et le mauvais CVE

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 les 20 et 21 juillet, un lot conséquent de 432 CVE a été publié pour le noyau Linux. Cela ne signifie pas que 432 failles ont été corrigées, car le fonctionnement des CVE est différent pour le noyau. En revanche, ils correspondent quand même à des corrections portées dans la branche principale par les mainteneurs du noyau. Se pose alors la question de leur répercussion concrète.

D’abord, qu’est-ce qu’un CVE ? C’est un identifiant unique (Common Vulnerabilities and Exposures) attribué à une faille de sécurité informatique connue publiquement. Une telle vulnérabilité se définit par une faiblesse de la logique d’un logiciel, permettant alors à un attaquant de violer la politique de sécurité et d’effectuer des actions auxquelles il n’a normalement pas droit. Dans la plupart des cas, les CVE sont publiés avant les correctifs associés, car ils servent souvent de base pour les bulletins de sécurité. Le CVE s’accompagne généralement d’un score CVSS (Common Vulnerability Scoring System), censé représenter le niveau de dangerosité de la faille, et de détails contextuels (vecteur d’attaque à distance, niveau de privilèges requis, etc.).

• CVSS 4.0 : dur, dur, d’être un expert !

Il y a CVE et CVE

Les CVE sont attribués par les CNA (CVE Numbering Authorities). Or, depuis février 2024, le projet Linux est devenu sa propre autorité de numérotation, avec des règles spécifiques pour répondre à l’échelle de son immense base de code.

Pour comprendre la situation actuelle, il faut retenir que ces règles sont inversées par rapport au reste de l’industrie. Dans un cas classique, la découverte d’une faille entraine l’attribution d’un CVE, l’alerte puis le développement du patch. Que les détails soient parfois publiés plus tard n’y change rien, le CVE est attribué d’abord. Au sein du projet Linux, c’est le contraire : la découverte d’une faiblesse dans le code entraine le développement d’un patch puis la fusion de celui-ci dans les branches stables du noyau, et seulement après l’apparition d’un CVE. Ce qui signifie qu’au sein du noyau Linux, les failles non corrigées n’ont pas de CVE.

Autre précision importante : l’équipe du noyau attribue systématiquement un CVE à tout correctif de bug susceptible d’impacter la stabilité ou l’accès mémoire, sans chercher à qualifier si le bug est facilement exploitable ou non. C’est ce qu’expliquait sur son blog Greg Kroah-Hartman, mainteneur principal des branches stables du noyau, en février dernier. De même, aucun score CVSS n’est produit, et pour cause : les développeurs du noyau ne connaissent pas l’usage fait de Linux, donc dans quel type d’environnement le code sera exécuté.

En revanche, là où un CVE traditionnel décrit un comportement de haut niveau, un CVE Linux correspond directement à un identifiant de commit Git. Ce suivi automatisé explique pourquoi l’utilisation massive de fuzzers et d’outils d’analyse statique génère des pics soudains de plusieurs centaines de CVE.

Mais alors, où est le problème ?

Si la publication de 432 CVE est en soi inédite, ils correspondent donc à des bugs déjà corrigés. Pourtant Jan Schaumann, architecte en chef de la sécurité de l’information chez Akamai Technologies, s’en est plaint sur la liste de diffusion OSS-SEC. Il y exprime son inquiétude devant un tel volume, demandant comment les entreprises, et de manière générale les environnements de production, peuvent suivre un tel rythme.

Mais en quoi est-ce un problème ? Si les failles sont déjà corrigées, ne suffit-il pas d’attendre sagement la prochaine révision du noyau ? Ce n’est pas si simple.

Plusieurs éléments doivent être considérés. D’un côté, les corrections intégrées aux branches stables signifient que toutes les versions actuellement supportées du noyau Linux vont les répercuter. En théorie, il suffirait d’installer la version suivante dans la branche utilisée, par exemple la 7.2 si l’on utilise une distribution évoluant avec les versions les plus récentes. De l’autre, les environnements de production utilisent souvent des versions modifiées, voire d’anciennes versions dans lesquelles les équipes « backportent » (rétroportent) les modifications qui les intéressent.

C’est là que survient le problème dont se plaint Jan Schaumann : quand 432 CVE sont publiés en 24 heures, comment savoir ce qui est important et doit être rétroporté ? Dans un courrier envoyé à The Register, il évoque la possibilité de faire travailler des LLM pour gérer automatiquement le flux. « Des mises à jour automatisées, régulières et fréquentes qui intègrent tous les changements dans un délai donné me semblent la seule approche raisonnable, mais cela est très difficile pour de nombreuses grandes organisations », explique-t-il ainsi.

Le dernier noyau disponible, toujours

Sur la liste de diffusion OSS-SEC, la discussion présente des réponses intéressantes, notamment celle de Greg Kroah-Hartman en personne. Bien qu’il ne réagisse pas directement au message initial, les solutions envisagées par d’autres sont passées en revue, et il donne nettement sa préférence : toujours utiliser le dernier noyau stable disponible sur la branche souhaitée et vérifier régulièrement l’ensemble des systèmes gérés.

Kroah-Hartman reconnait que ce n’est pas toujours simple au sein des entreprises, mais que des produits payants permettent de gérer efficacement ce processus. Si payer un tel produit n’est pas possible, il recommande d’installer des distributions comme Debian ou Yocto, car « leurs pratiques de sécurité sont extraordinaires ». Les autres solutions représentent plus de travail ou une sécurité moindre. Vérifier un par un les CVE pour ne considérer que ceux importants dans l’infrastructure ? On peut le faire de manière automatisée pour vérifier ce qui ressort à l’intersection des fichiers visés par les CVE et des fichiers réellement utilisés dans l’environnement géré. Mais on en revient à la proposition de Jan Schaumann, et toutes les organisations ne peuvent pas se permettre un tel pipeline de gestion.

En d’autres termes, la meilleure solution reste la répercussion des nouveaux noyaux quand ils deviennent disponibles, mais l’explosion du nombre de CVE – très probablement portée par l’utilisation croissante des LLM – rend la lecture plus complexe. Pour Greg Kroah-Hartman cependant, il n’y a pas vraiment de problème : les 432 CVE étaient en préparation depuis des semaines, personne ne devrait être surpris.

Première fois, mais pas la dernière

Dans un billet de blog, l’entreprise explique comment l’apparition d’une faille critique dans le moteur de virtualisation KVM a entrainé une vaste campagne de mises à jour dans ses infrastructures. Elle a choisi une approche radicale, avec un impact assumé sur les clients, prévenus en amont.

L’incident débute le 6 juillet, quand les détails d’une faille critique apparaissent. Estampillée CVE-2026-53359 et surnommée Januscape, elle réside dans le code de shadow paging du moteur de virtualisation KVM sur l’architecture x86.

« KVM constitue le moteur de virtualisation sur lequel repose l’immense majorité des instances hébergées chez OVHcloud. Le mécanisme est le suivant : lorsqu’une modification externe d’un Page Directory Entry (PDE) survient, l’entrée RMAP peut conserver une référence vers une page mémoire déjà libérée. Le noyau déréférence ensuite cette page obsolète, ce qui peut entraîner un plantage de l’hyperviseur ou, dans les scénarios les plus défavorables, une élévation de privilège côté hôte. L’exploit est reproductible : un test interne sur un hôte non patché provoque un crash en environ deux minutes », explique OVHcloud dans son billet.

Le lendemain, OVHcloud déclenche une cellule de crise pour aborder la situation, avec la question centrale : comment mettre à jour des dizaines de milliers de serveurs hôtes hyperviseurs, représentant environ un million de machines virtuelles ?

Cinq solutions, aucune idéale

Comme l’entreprise l’explique dans son billet, cinq possibilités étaient sur la table. Elle pouvait attendre l’arrivée des noyaux Linux officiels mis à jour, mais elle aurait été alors « tributaire d’un agenda tiers ». Un live patch ? Une opération « sensible par nature », qui permet de gagner du temps mais entraine aussi une réduction du niveau de durcissement et une baisse des capacités de détection en cas de compromission.

OVHcloud a considéré rapidement la désactivation de la virtualisation imbriquée, qui permet notamment de lancer des machines virtuelles à l’intérieur d’autres machines virtuelles. La solution est écartée, faute de pouvoir mesurer l’impact sur les clients.

Une piste plus sérieuse était la migration live, depuis des hôtes vulnérables vers d’autres vides et patchés. L’option est décrite comme « très satisfaisante » pour la continuité, sans impact sur les machines virtuelles. Elle a toutefois un sérieux désavantage : elle prend beaucoup de temps. OVHcloud la garde sous le coude pour certaines machines critiques.

La solution adoptée consiste finalement à mettre les mains dans le cambouis, en intégrant soi-même le patch dans les noyaux utilisés, en diffusant ces derniers et en redémarrant la totalité des hôtes.

Un « patching unilatéral à impact contrôlé »

Le choix de cette solution est « assumé », selon OVHcloud. Elle affirme qu’il s’agissait de la seule solution possible pour tenir compte des paramètres : la criticité de la faille, le nombre de machines à traiter et le degré de perturbation pour les clients. « Une action rapide et globale protège le plus grand nombre, quitte à impacter une minorité de manière temporaire », ajoute OVHcloud.

Tout s’est très vite enchainé. Le soir du 7 juillet, le « backport » du correctif est réalisé dans le noyau et les tests de validation commencent. Dans les heures qui suivent, les équipes confirment que le noyau mis à jour n’est plus sensible à la faille. Dans la foulée, le comité exécutif donne son feu vert pour un déploiement dès le lendemain matin.

OVHcloud n’a cependant pas déclenché ce déploiement sur la totalité des machines virtuelles au même instant. L’opération commence dans la région Sydney, avec plusieurs avantages : le nombre d’hôtes est limité, la plage de déploiement correspond aux heures de bureau en France et l’entreprise pourra collecter les premiers retours, avant de se tourner vers des déploiements plus importants. Le 8 juillet, en début d’après-midi (heure de Paris), tous les hôtes VPS (Virtual Private Server) de la région sont mis à jour et redémarrés.

L’entreprise suit littéralement le soleil : « Chaque région prend le relais à son tour, sur sa matinée locale, en transmettant le contexte à la suivante ». Elle estime avoir récolté assez de retours pour lancer la première vague européenne sur les VPS (RBX, GRA6, WAW, DE, SBG, MIL, UK) à 18h30, toujours le 8 juillet. À chaque fois, les VPS sont migrés les premiers, l’offre Public Cloud présentant d’autres défis. Les régions à plus faible densité sont traitées d’abord, tandis que celles à fort volume sont « orchestrées avec une granularité plus fine, lot par lot, pour diluer le risque ».

Plusieurs mécanismes ont été mis en place pour limiter les risques pendant les opérations, notamment des seuils d’arrêt. Chaque vague de redémarrages était bornée par un seuil d’arrêt automatique : 15 hôtes en panne simultanée pour les régions à forte densité (GRA, RBX, BHS), 5 hôtes pour les autres, avec arrêt systématique à 06h00 locales ou sur demande du centre de données. Ce mécanisme vise à ne pas superposer des redémarrages supplémentaires à une situation de panne matérielle déjà en cours de traitement.

Les orchestrateurs ont en outre calculé un graphe de co-localisation par projet et ont défini des vagues mutuellement exclusives. Ainsi, deux hôtes portant des instances du même projet ne sont jamais redémarrés dans la même fenêtre, un hôte devant être revenu en service avant le lancement du suivant dans la même classe. Cette règle est appliquée en « best effort », non garantie à 100 % sur l’ensemble du parc.

Des incidents quand même

Malgré les précautions, des problèmes sont quand même apparus. Certaines machines virtuelles n’ont pas redémarré après le reboot de leur hôte, dès la première vague européenne. Un conflit a été détecté entre libvirt-guests.service et Nova Compute, provoquant l’arrêt des instances sans synchronisation API.

Dès le deuxième jour, un problème de corruption de données est apparu sur des services synchrones. Des machines virtuelles réparties sur trois clusters ont présenté des données corrompues, à cause probablement d’un redémarrage forcé en pleine écriture disque. La période d’attente avant kill forcé a été étendue à 60 secondes, et un script de redémarrage automatique des VM restées éteintes a été déployé.

À Paris, dans la nuit du deuxième au troisième jour, des soucis de saturation mutuelle sont apparus entre les API Nova et Neutron. Cette dernière plafonnant à 10 processus, la situation a provoqué deux heures de panne HTTP 503. Le correctif appliqué a consisté à augmenter le nombre de workers Neutron de 10 à 30 et celui des processus Apache de 10 à 32.

Sur le plan matériel, environ 20 à 30 hôtes sur 6 000 ne sont pas revenus seuls après la première nuit de redémarrages (barrettes mémoire défaillantes, configuration BIOS, interfaces réseau inactives), indique OVHcloud. Certains cas aux États-Unis ont même nécessité un retrait de la batterie CMOS et un drain d’alimentation. Des techniciens ont été mobilisés en renfort sur chaque site pour intervenir en priorité sur les hôtes en échec.

En tout, l’opération s’est étalée sur 11 jours.

Ce type d’opération se reproduira, assure OVHcloud

Côté communication aux clients, la stratégie retenue a été l’envoi de messages ciblés de manière progressive, déclenché région par région et vague par vague, aux seuls clients concernés par les hôtes programmés.

Le choix initial de ne pas ouvrir de page publique de statut visait à ne pas exposer la séquence de déploiement, un arbitrage voulu entre transparence et risque (éviter d’inciter des clients à tester l’exploit). Les limites de ce dispositif sont pointées par OVHcloud : pour GRA6 (près de 90 000 clients non contactés), l’envoi massif d’e-mails a été écarté pour ne pas saturer le support, ce qui a conduit à un pivot vers une bannière conditionnelle dans le Manager (basée sur une liste de comptes impactés) le lendemain et – finalement – la création d’une page de statut Public Cloud le jour suivant.

En revanche, malgré les détails fournis par l’entreprise, le descriptif est essentiellement qualitatif : on ne connait pas le nombre total d’incidents clients, la durée cumulée d’indisponibilité, ni les éventuelles compensations.

L’entreprise indique en tout cas avoir tiré des enseignements de cette migration, car elle n’avait jamais été confrontée à une situation critique d’une telle ampleur, les épisodes précédents ayant été traités par rotation naturelle du parc combinée à des migrations live planifiées sur une durée longue.

OVHcloud se veut claire également : ce type de procédure d’urgence est amené à se reproduire compte tenu du rythme des publications de vulnérabilités noyau, sous l’impulsion de l’IA générative notamment. Les axes d’amélioration identifiés par l’entreprise portent sur trois points : la maîtrise de l’impact brut des redémarrages, l’information en amont des clients, et la procédure d’accompagnement des clients impactés. L’entreprise évoque donc un « exploit » réalisé par ses équipes, mais ajoute : « Nous devrons faire mieux la prochaine fois, aussi bien dans la maîtrise de l’impact brut des redémarrages que dans l’information en amont des clients et dans la procédure d’accompagnement des clients impactés lors des opérations ».