Un fournisseur Linux aime l’idée, mais les analystes et les utilisateurs la considèrent comme une arme à double tranchant.
Les administrateurs de serveur Linux peuvent avoir la possibilité de désactiver une fonction vulnérable dans le noyau du système d’exploitation jusqu’à ce qu’un correctif pour une vulnérabilité zero-day soit prêt, si une proposition d’un développeur et mainteneur du noyau est acceptée par la communauté open source.
L’idée d’un kill switch pour les opérateurs privilégiés a été suggérée par Sasha Levin, ingénieur distingué chez Nvidia et co-responsable du support à long terme et des arborescences stables du noyau Linux, comme mesure d’atténuation lorsqu’une faille de sécurité est découverte.
Comme il l’a souligné dans un article récent, lorsqu’une vulnérabilité est découverte, « les flottes restent exposées jusqu’à ce qu’un noyau corrigé soit construit, distribué et redémarré. Pour beaucoup de ces problèmes, la solution la plus simple consiste à arrêter d’appeler la fonction buggy ». Dans son article, Levin et un collègue ont également proposé une version proposée d’un kill switch du noyau.
« Pour la plupart des utilisateurs », a souligné Levin, « le coût de ‘cette famille de sockets cesse de fonctionner pour la journée’ est bien inférieur au coût de fonctionnement d’un noyau vulnérable connu jusqu’à ce que le correctif soit disponible. »
La proposition intervient à un moment où plusieurs vulnérabilités Linux de grande gravité ont été découvertes, notamment Copy Fail (un bug logique CVE-2026-31431 qui permet aux utilisateurs d’obtenir facilement un accès root, et Dirty Frag, qui exploite les faiblesses de la façon dont le noyau Linux gère les pages de mémoire fragmentées. L’attaque Dirty Frag combine deux vulnérabilités distinctes affectant le sous-système Linux IPsec Encapsulated Security Payload (ESP) (CVE-2026-43284) et le protocole réseau RxRPC (CVE-2026-43500).
Les utilisateurs du forum de sécurité s’y opposent
La proposition a déclenché un débat furieux parmi les professionnels de la sécurité de l’information. Par exemple, sur le forum Reddit r/cybersecurity, cette idée a été qualifiée de « terrible idée », de « ridicule », de « absolument terrifiante » et de « tout simplement trop risquée ».
« Les gens utiliseront un kill switch au lieu d’appliquer des correctifs », a soutenu un contributeur.
« Si vous savez comment fonctionne Linux, vous n’en avez pas besoin », a ajouté un autre contributeur, qui a déclaré que quelques heures après la sortie de l’exploit Dirty Drag, il avait analysé le code et préparé des mesures d’atténuation. « Si vous ne savez pas comment fonctionne Linux », a-t-il ajouté, « vous ne devriez pas utiliser de kill switch ».
Les experts Linux et la sécurité sont prudents.
« Il est facile pour un développeur de dire ‘Déchargez simplement ce module du noyau’, mais le plus difficile est d’attester de l’entreprise qu’il n’y a aucun impact sur les services. À ce moment-là, je me demande pourquoi ce module a été chargé s’il n’a jamais été nécessaire ? Cela ressemble à une lacune dans mon processus de renforcement et de construction », a-t-il déclaré.
Meghu prévoit au moins deux problèmes avec un kill switch : Premièrement, peu d’administrateurs sont en mesure d’évaluer facilement son impact sur les services de leur organisation. Un kill switch fonctionnerait facilement pour le problème de Copy Fail, a-t-il déclaré, « mais en tant que stratégie pour tous les risques potentiels ? Quel sera l’impact sur le changement de la désactivation des fonctions du noyau ? Il faudrait le tester et le valider, et cela prend encore du temps et des efforts pour être véritablement validé en dehors de la production. »
Deuxièmement, a-t-il ajouté, le simple fait de déclencher le kill switch et d’espérer n’est pas une bonne stratégie pour les applications prises en charge par les entreprises.
Le problème de l’échec de copie n’est pas typique de tous les problèmes auxquels les professionnels de Linux sont confrontés, a ajouté Meghu. En bref, dit-il, le kill switch « ressemble à un pansement qui ne fonctionne que sur certaines coupures ».
Robert Enderle du groupe Enderle a déclaré que la proposition de coupe-circuit est un outil classique de « bris de vitre en cas d’urgence ». Il a déclaré : « Pour les administrateurs d’entreprise, il s’agit d’une réponse très pragmatique au décalage entre une divulgation Zero Day et un correctif déployé. Dans les environnements à haute disponibilité où le redémarrage d’une flotte est un cauchemar, être capable de supprimer une fonction spécifique non essentielle (comme un protocole réseau obscur) qui est actuellement exploitée est une énorme victoire. Il s’agit essentiellement d’échanger une fonctionnalité de niche contre l’intégrité immédiate du système sans le temps d’arrêt d’un cycle complet de correctifs. «
Cependant, a-t-il ajouté, ce pouvoir serait une arme à double tranchant. « Bien que cela ne crée pas de nouveau point d’entrée – vous avez toujours besoin d’un accès root pour appuyer sur la gâchette – cela ouvre la porte à un déni de service massif auto-infligé. Il n’y a pas de filet de sécurité ; si un administrateur tue par erreur une fonction critique de gestion de la mémoire, le système est grillé. «
Il a souligné que cela risque également de devenir une béquille permettant aux organisations de retarder l’application des correctifs. « C’est un outil pointu qui appartient aux équipes de sécurité sophistiquées, mais pour l’administrateur système moyen, il est probablement un peu trop « nucléaire » pour être confortable », a-t-il déclaré. « Compte tenu de la manière dont le personnel informatique est présent de nos jours, cela est probablement beaucoup trop dangereux pour que la plupart d’entre eux envisagent de l’utiliser. »
Mais un responsable du distributeur Linux Red Hat a déclaré que la société pensait que cela fonctionnerait.
