GhostLock : dans les coulisses de la sécurisation de 6 000 applications

Contexte

Le 8 juillet 2026, alors que nous sommes tous réunis à Strasbourg pour notre habituel événement trimestriel, une alerte se déclenche au sein de l’équipe sécurité. Une nouvelle faille de sécurité fait parler d’elle, la CVE-2026-43499, de son nom “GhostLock”. Il s’agit d’une vulnérabilité affectant le noyau Linux et dont la classification de base par l’éditeur (score CVSS) est de 7.8/10. Dans le contexte spécifique de la plateforme Scalingo, ce score atteint 9.4/10.

Cette vulnérabilité a été découverte dans le cadre d’IonStack, et permet, une fois combinée avec une autre vulnérabilité, d’obtenir un accès complet (root) à un système Android, à distance, avec un simple clic d’un utilisateur.

Cette vulnérabilité nous interpelle, et l’équipe sécurité décide donc de s’en saisir. Les chercheurs décrivent une chaîne d’exploitation permettant une élévation de privilèges avec une fiabilité annoncée d’environ 97 %. Le PoC public disponible au moment de notre analyse démontrait notamment un déni de service par kernel panic. Cette vulnérabilité, introduite dans la version 2.6.39 de Linux sortie en 2011, est présente dans un très grand nombre de systèmes. Plus inquiétant encore, cette vulnérabilité ne repose que sur des fonctionnalités standard du noyau Linux.

Depuis le début de l’année, nous avions déjà été confrontés à plusieurs vulnérabilités de criticité élevée. Jusqu’à présent, celles-ci concernaient toutefois des modules du noyau activés par défaut, mais très rarement utilisés en pratique chez Scalingo. Nous avions ainsi pu mettre en œuvre rapidement des mesures de mitigation simples et maîtrisées : désactiver les modules vulnérables, sans redémarrage des machines, puis déployer cette action de manière industrialisée sur plusieurs centaines de serveurs.

Dans le cas présent, GhostLock ne repose sur aucune fonctionnalité désactivable, car il n’utilise que des fonctionnalités de base du système (pthread_mutex / futex operations).

Nous n’avions alors reproduit que le déni de service démontré par le PoC public. Les chercheurs décrivaient néanmoins une chaîne plus avancée permettant une élévation de privilèges et une sortie de conteneur, scénario que nous avons jugé suffisamment crédible pour agir immédiatement.

Plan d’action et mise en place de la cellule de crise

Dès lors que nous avons pris connaissance de ces informations, notre première préoccupation a été de vérifier si la plateforme Scalingo était vulnérable. Le résultat ne s’est pas fait attendre : en quelques minutes, nous avons réussi à faire crasher 2 systèmes sur 3 testés dans notre environnement de préproduction. Concrètement, pour Scalingo, cela signifie qu’un utilisateur mal intentionné pourrait mettre en défaut suffisamment de serveurs pour créer un problème global.

Face au risque à présent avéré, un seul objectif : l’éliminer. Le POC (proof-of-concept) rendu disponible par les chercheurs en cybersécurité n’est guère rassurant : aucun workaround complet n’existe. Le seul correctif connu à ce jour pour les systèmes Ubuntu est une mise à jour du noyau vers la version 7.0.0-27.27, fraîchement rendue disponible par Canonical, l’entreprise derrière Ubuntu.

Cependant, ce noyau n’est disponible que pour la dernière version, Ubuntu 26.04, sortie en avril. Comme la majorité de l’industrie, Scalingo n’exploite pas encore cette version sur ses serveurs. Le travail pour mettre à jour notre infrastructure vers Ubuntu 26.04 avait démarré récemment, mais n’était alors que dans une étape préliminaire de planification et avait été mis en pause pour la durée de notre événement d’entreprise.

Face au peu de solutions alors à notre disposition, une décision simple a été prise : concentrer toute l’équipe d’infrastructure sur le projet Ubuntu 26, pour réaliser l’ensemble du travail nécessaire et le livrer au plus vite en production, en ciblant en priorité les serveurs hébergeant des conteneurs applicatifs de nos clients.

Chez Scalingo, chacun de nos serveurs possède un rôle qui définit la configuration et l’ensemble des services qui s’exécutent sur ce dernier. Pour cette vulnérabilité, deux types de serveurs sont à risque :

• Les serveurs hébergeant les conteneurs des applications des clients : c’est le risque majeur. Un utilisateur malveillant pourrait facilement faire planter en chaîne plusieurs dizaines de serveurs, impactant un nombre significatif de nos clients.

• Les serveurs assurant la construction de l’image Docker lors d’un déploiement : le risque serait ici de rendre indisponible la création de nouveaux déploiements. Toutes les applications déjà hébergées sur la plateforme continueraient de fonctionner normalement, mais il ne serait alors plus possible de réaliser de nouveaux déploiements. Bien que l’impact soit également non négligeable ici, ce type de serveur reste moins critique que les serveurs hébergeant directement les applications clientes.

Décision est donc prise d’axer le travail sur les serveurs hébergeant les conteneurs applicatifs clients. Nous gardons en tête les serveurs assurant la construction d’images, mais prévoyons de les traiter dans un second temps.

C’est au même moment que nous montons une cellule de crise, sous la tutelle du RSSI et comprenant la direction, le CTO, le Lead Technique ainsi que l’équipe d’infrastructure. Le RSSI est chargé de tous les aspects autour du suivi de l’évolution de la vulnérabilité et de la communication interne et externe autour de cette dernière, notamment la préparation d’un bulletin de sécurité. Le CTO et le Lead Technique cadrent le plan technique et s’assurent de son bon déroulement, tout en prêtant main forte à l’équipe d’infrastructure qui est chargée de sa bonne exécution.

L’équipe d’infrastructure est donc déchargée de ses missions prévues pour la semaine. Ces dernières seront reprises par d’autres équipes (notamment SRE), pour pouvoir se concentrer sur ce travail.

Implémentation technique et challenges

Chez Scalingo, lorsque nous souhaitons mettre à jour un serveur d’une version Ubuntu à une autre, nous n’allons pas nous connecter au serveur et exécuter à la main la procédure d’assistance de mise à jour comme nous pourrions le faire sur nos ordinateurs personnels. En réalité, nous ne mettons pas à jour le serveur : nous créons une nouvelle machine virtuelle avec la nouvelle version, vidons l’ancienne machine puis la supprimons. Il s’agit d’une approche majoritairement utilisée dans l’industrie, et bien plus efficace qu’une opération de mise à jour manuelle.

Pour pouvoir démarrer une VM sur une nouvelle version d’Ubuntu, il y a deux grandes étapes :

• Créer une image personnalisée d’Ubuntu 26.04 (dite OMI ou AMI dans le monde AWS) ;

• Faire fonctionner Chef, notre outil de configuration et de déploiement des logiciels sur nos serveurs, sur Ubuntu 26.04.

Étant donné que nous étions alors tous présents physiquement à Strasbourg, nous avons pu en profiter pour nous réunir dans une même pièce et répartir rapidement les tâches au sein de l’équipe d’infrastructure. Bien que nous ayons l’habitude de travailler à distance, le fait d’être à côté permet de suivre en un coup d’œil l’avancement de chacun et de débloquer des situations plus efficacement.

Notre travail a donc débuté par la création d’une OMI. Il s’agit d’une image machine qui va servir de base lors de la création de nos machines virtuelles (VM). Une OMI définit la version du système à démarrer (dans notre cas, Ubuntu 26.04), les paramètres à passer au noyau lors du démarrage, et d’autres configurations élémentaires. Une OMI peut également contenir des logiciels et configurations diverses, qui seront alors directement disponibles dès le premier démarrage de la VM. Chez Scalingo, nos OMI sont relativement simples. Nous devrions donc pouvoir disposer rapidement d’une version fonctionnelle en Ubuntu 26.04.

En parallèle, nous devions faire fonctionner Chef sur Ubuntu 26.04. Chef est le logiciel s’exécutant sur toutes nos VM et qui est responsable de leur configuration et du déploiement de tous les logiciels en fonction du rôle de chaque machine. Nous étions plus fébriles quant à son exécution sur Ubuntu 26.04 pour plusieurs raisons :

• Notre version de Chef n’est pas à jour, en raison de l’hétérogénéité de notre parc. En effet, nous devons rester sur une ancienne version de Chef pour que ce dernier fonctionne sur des machines qui ont d’anciennes versions d’Ubuntu ;

• Même si Chef fonctionne, certains cookbooks (les dépendances dans l’écosystème Chef) que nous utilisons pourraient ne pas prendre en charge Ubuntu 26.04, qui reste une version relativement récente ;

• Certains de nos logiciels nécessaires au fonctionnement de la plateforme pourraient nécessiter des modifications pour fonctionner sur Ubuntu 26.04 ;

• Enfin, en passant à 26.04, beaucoup de composants vont changer de version majeure, notamment Docker. Tout pourrait ne pas être compatible avec cette version.

C'est avec ces incertitudes en tête que nous commençons à faire tourner Chef sur Ubuntu 26.04 dans notre environnement de développement. Si nous rencontrons effectivement quelques difficultés, elles restent limitées. Peu d'adaptations sont finalement nécessaires, notamment parce que les nœuds hébergeant les conteneurs de nos clients n'exécutent qu'un nombre restreint de nos logiciels.

Plan de déploiement

En parallèle de ce travail, nous commençons à réfléchir au moyen de migrer rapidement, et avec le minimum d’impact possible, l’ensemble des applications vers des serveurs non vulnérables à jour. Nos outils d’orchestration actuels nous permettent de facilement vider une machine, en répartissant les conteneurs qui s’y trouvent sur d’autres serveurs. Cependant, les enjeux allaient bien au-delà. Nous voulions vider un maximum de nœuds le plus rapidement possible, sans impact visible sur les applications clientes ni contention excessive liée à la migration simultanée de centaines de conteneurs.

Nous avons donc conçu une stratégie en deux parties :

• Créer autant de nouvelles VM applicatives que possible avec Ubuntu 26.04 ;

• Migrer tous les conteneurs d’un nœud A vulnérable vers un nouveau nœud B, patché, en capitalisant sur la fonctionnalité de migration de conteneurs de la plateforme qui permet de faire ceci sans impact pour les applications clientes.

Cette approche permet de contrecarrer les limitations d’orchestration que nous connaissons :

• Notre algorithme de migration de conteneurs n’a pas été conçu initialement pour migrer autant d’applications en si peu de temps. En effet, lors d’une migration, le scheduler va, par défaut, prendre chaque application, et pour chaque conteneur de l’application, démarrer un nouveau conteneur sur une autre machine qu’il aura jugé comme la plus adaptée. Cet algorithme fonctionne bien lorsqu’il s’agit de vider un nœud, mais passe assez mal à l’échelle. Quand beaucoup de conteneurs sont déplacés en même temps, le scheduler a tendance à choisir à plusieurs reprises la même machine de destination, et donc à lui générer une charge importante en lui demandant de démarrer beaucoup de conteneurs d’un coup. Ce comportement avait déjà causé un incident lors d’une précédente opération de maintenance. C’est pourquoi nous avons décidé d’écrire un script permettant de “transférer” les conteneurs d’un serveur A vers un serveur B. L’idée est assez simple : pour chaque serveur d’application vulnérable, nous allons créer son alter ego en Ubuntu 26.04 (patché). Une fois le serveur prêt, le script va prendre les conteneurs du serveur initial, un à un, et les déplacer sur le serveur Ubuntu 26.04. En laissant assez de délai entre deux conteneurs, nous avons toujours un flot de démarrage constant sur les nouveaux serveurs, sans impact visible car il n’y a jamais plus de 3 à 4 conteneurs qui démarrent sur un même nœud.

• Pour ce qui est de la création de nouvelles VM sur Ubuntu 26.04, nous faisons ici face à une limitation technique. Sur la région osc-fr1, le réseau virtuel qui contient toutes les machines applicatives a une taille limitée, et ne nous permet donc pas de doubler le nombre de machines disponibles. En effet, ce réseau n’aurait pas assez d’IPs pour adresser toutes les machines. Il s’agit d’une limitation que nous connaissons, et des changements structurants d’infrastructure sont en cours depuis plusieurs mois pour ne plus subir une telle limite. Cependant, dans le cas présent, nous devions faire avec.

  Ainsi, nous avons donc procédé par système de batch. L’idée est de créer autant de nouvelles VM que possible en Ubuntu 26.04. Quand elles seront créées, nous migrerons tous les conteneurs applicatifs des premières VM non patchées vers les VM Ubuntu 26.04. Dès que les VM non patchées seront complètement vides, nous les supprimerons, libérant leurs IPs, et continuerons avec un second batch, jusqu’à n’avoir plus que des machines tournant sur Ubuntu 26.04 patché. Avec sa taille actuelle, nous aurons besoin de quatre batches pour traiter l’ensemble de la région osc-fr1.

  Sur notre seconde région, osc-secnum-fr1, le problème est plus simple. La région étant plus petite, nous pouvons donc, en une seule fois, créer assez de VM pour doubler temporairement la taille de la région. Il ne nous reste ensuite plus qu’à migrer tous les conteneurs de nœuds non patchés à des nœuds patchés.

  
  

Décision de mise en pause pour la nuit

Au soir de cette première journée, nous avons une AMI Ubuntu 26.04 prête et Chef s’exécute sur notre environnement local sur une machine de type applicative. Cependant, nous devons encore créer une VM en condition réelle sur notre infrastructure de préproduction, et surtout, exécuter toute la phase de QA (assurance qualité) sur cette dernière, avant d’envisager un passage en production. Cette étape ne doit pas être sacrifiée au prix de l’urgence, au risque de créer un incident plus grave que le problème original.

Conscients que ce travail nécessitera plusieurs heures, et que, même avec beaucoup d’efforts, la plateforme ne pourra pas être mise en sécurité pour le lendemain, nous décidons d’arrêter le travail à cette étape pour ce soir.

Pour réduire la surface d’exposition, nous avons temporairement suspendu les nouvelles inscriptions et renforcé la supervision de la plateforme jusqu’à la reprise du déploiement.

QA et déploiement

Le lendemain, une première VM exécutant Ubuntu 26.04 est créée sur notre environnement de préproduction. Nous passons l’intégralité de la matinée et le début de l’après-midi à dérouler nos procédures de vérifications (QA) et apporter des correctifs aux quelques problèmes mineurs que nous identifions. Nous confirmons également qu’il n’est plus possible de mettre en défaut le système, ce qui reste la raison principale nous ayant amenés à conduire ce travail en urgence.

C’est à 17 heures que nous démarrons le déploiement en production sur la région osc-secnum-fr1. En une heure, la taille du parc applicatif est doublée et une dernière série de vérifications sur les nouveaux nœuds, directement en production, est exécutée. Une fois cette validation obtenue, tous les anciens nœuds sont marqués comme non éligibles à accueillir de nouveaux conteneurs, laissant uniquement des nœuds patchés à disposition.

À 18h15, chaque VM est en train de migrer tous ses conteneurs vers une machine Ubuntu 26.04, selon la procédure définie la veille, et de façon transparente pour les clients. La migration prendra quelques heures et finira dans la soirée. La seule trace visible sera un événement, disponible dans la timeline Scalingo de chaque application, indiquant un redémarrage des conteneurs pour des raisons “d’équilibrage de charge”.

Le déploiement sur osc-fr1 sera, lui, lancé un peu plus tardivement pour deux raisons. Premièrement, nos quotas nécessitaient une augmentation pour nous permettre de créer autant de VM d’un coup. De plus, notre fournisseur d’infrastructure faisant face à un incident à ce moment (sans lien avec les opérations menées de notre côté), nous avons donc attendu un rétablissement complet et une stabilisation avant de lancer le premier batch.

À 21h30, le premier batch est démarré et une série de machines non patchées commencent à déplacer leurs conteneurs vers des serveurs à jour.

En fin de soirée, une bonne partie des nœuds du premier batch sont vides. La journée finit aux alentours de 0h20, alors que les derniers serveurs du premier batch finissent de déplacer leurs conteneurs. La création de nouveaux comptes est à nouveau désactivée dans la nuit.

Le lendemain, la journée commence avant 8h pour enclencher un deuxième batch. Avant de pouvoir le faire, nous devons traiter les applications récalcitrantes qui ont refusé d’être migrées vers les nouveaux serveurs automatiquement. En effet, si notre algorithme n’est pas en mesure de démarrer un conteneur fonctionnel sur un nouveau nœud, il préfère le laisser continuer de tourner sur son nœud actuel, plutôt que de rendre l’application indisponible.

Il existe plusieurs raisons pour lesquelles un conteneur peut ne pas être en mesure de démarrer, la plus évidente étant une surconsommation de mémoire au démarrage (qui fait donc planter le conteneur peu après le lancement), par rapport à la mémoire nécessaire dans le cycle d’exécution normal. Étant donné qu’il n’existe pas de moyen universel pour traiter ces comportements, c’est manuellement que pour chaque conteneur ayant refusé de démarrer, nous devons conduire une rapide analyse afin de procéder à la migration dudit conteneur. Même avec un faible nombre de conteneurs présentant un tel comportement sur chaque nœud, cette opération prend rapidement beaucoup de temps.

Une fois cette étape manuelle faite, nous enchaînons directement avec le deuxième batch. À midi, 60% des nœuds de la région osc-fr1 sont sur la version patchée, Ubuntu 26.04.

À 20h30, une troisième vague de migration est lancée. Enfin, à 23h15, tous les nœuds pouvant accueillir des conteneurs applicatifs sont sur Ubuntu 26.04, et les dernières applications sont en cours de migration. À ce moment, la plateforme est entièrement sécurisée car il n’existe plus aucun moyen de démarrer un conteneur applicatif sur un nœud présentant la vulnérabilité.

La migration des dernières applications finira dans la nuit, alors que notre travail, lui, s’arrête ici.

En 30 heures environ, nous aurons migré plus de 6 000 applications, 19 000 conteneurs représentant plus de 5 PB de RAM, deux régions confondues. Ces migrations se sont exécutées en transparence et sans impact pour les utilisateurs.

Travail sur les serveurs assurant les déploiements

Le lundi suivant, veille de fête nationale, nous prenons la décision de débuter le travail sur le second type de serveur qui est encore exposé à cette vulnérabilité, c’est-à-dire les serveurs responsables des déploiements.

Le travail est enclenché en début de journée, et se déroule sans accroc, les seules difficultés ayant déjà été identifiées lors du travail de la semaine passée sur la partie applicative. En début d’après-midi, le premier nœud est disponible sur notre environnement de préproduction. La QA ne remontera pas de problème, permettant au déploiement en production de commencer dès 16 heures.

Nul besoin pour ces nœuds de mettre en place un complexe système de batch, nous pouvons simplement doubler temporairement le nombre de VM et désactiver le démarrage de nouveaux déploiements sur les anciennes, ce qui permet à tout nouveau déploiement de se lancer sur un serveur patché. Les anciens déploiements finissent eux sur des serveurs vulnérables, mais seront les derniers réalisés sur ces machines.

À 17h, l’ensemble des nouveaux déploiements lancés sur la région osc-secnum-fr1 le sont sur des nœuds patchés, tandis qu’il faudra attendre 18h pour la région osc-fr1. En fin de journée, l’ensemble du pipeline, du déploiement à l’exécution, est donc sécurisé contre GhostLock.

Ces serveurs seront les derniers patchés selon notre mécanisme d’urgence. Toutes les autres machines, qu’elles soient internes ou des nœuds de bases de données, suivront la politique de renouvellement standard des nœuds de Scalingo, comme indiqué dans le bulletin de sécurité qui a été publié au même moment.

Prise de recul, apprentissages et leçons tirées

Cet événement de sécurité nous aura permis de mettre à l’épreuve l’agilité de la plateforme et de nos équipes face à une situation de crise. Avec des procédures maîtrisées et un plan établi avec lucidité, moins de trois jours ont été nécessaires pour assurer la sécurisation de l’ensemble du parc applicatif.

L’intensification du développement de l’IA force les équipes Sécurité et Opérationnelles à réagir au plus vite, parfois contre des failles béantes présentes depuis des décennies. Face à ce rythme accru, l’automatisation est plus que jamais une nécessité. Même un nombre réduit d’actions manuelles peut impacter grandement la vitesse d’exécution lorsqu’il s’agit d’opérations à grande échelle à conduire dans un temps contraint. De plus, il est indispensable d’être équipé d’outils internes fiables, dans notre cas pour permettre des mouvements d’ampleur sur la plateforme tout en gardant un contrôle des opérations.

Plus que jamais, les fournisseurs IaaS, PaaS et SaaS doivent s’adapter dans un monde où les menaces s’intensifient et le besoin de sécurité augmente.