Le noyau divisé est la faille : pourquoi Copy Fail s’échappe du conteneur

8 Min. temps de lecture

Les conteneurs donnent l’impression d’être des espaces cloisonnés, pourtant ils partagent tous le même noyau du système hôte. Cette couche partagée constitue la véritable limite de l’isolation, et elle ne tient pas si le noyau lui-même présente une faille. La vulnérabilité récemment révélée Copy Fail en est l’illustration : un bug dormant dans le code depuis près d’une décennie, capable d’ouvrir l’ensemble du nœud sous-jacent à partir d’un seul conteneur compromis.

En lien :Failles du kernel Linux : le BSI met en garde contre l’escalade de privilèges root  /  Pourquoi la même classe de vulnérabilités revient sans cesse

La couche partagée que personne ne voit

Un conteneur isole les processus, les systèmes de fichiers et le réseau, mais il ne dispose pas de son propre noyau. Contrairement à une machine virtuelle, il s’exécute directement sur le noyau de l’hôte et le partage avec tous les autres conteneurs de la même machine. Cette couche commune est à l’origine de la légèreté des conteneurs, mais aussi de leur point le plus vulnérable. Quiconque compromet le noyau ne se trouve plus dans un conteneur, mais sur l’hôte.

Copy Fail exploite précisément cette particularité. Le noyau Linux gère un cache de pages global partagé, valable au-delà des limites des conteneurs, sans séparation par namespace. Un processus non privilégié dans un conteneur peut, via cette faille, écrire quelques octets contrôlés dans le cache d’un fichier accessible en lecture et ainsi obtenir des droits root. Comme le cache est partagé, l’accès en écriture s’étend à l’hôte et aux autres conteneurs.

Qu’est-ce qu’un container escape ? Un container escape désigne la fuite d’un attaquant hors de l’isolation d’un conteneur vers l’hôte sous-jacent ou vers des conteneurs voisins. Il est généralement rendu possible par le noyau partagé : en exploitant une vulnérabilité à ce niveau, on contourne la séparation que le conteneur est censé garantir.

Pourquoi l’âge de la faille ne doit pas rassurer

Copy Fail n’est pas une erreur de programmation récente, mais était présent depuis le noyau 4.14, soit depuis environ neuf ans. Ce n’est pas un cas isolé, mais un schéma : des classes d’erreurs survivent longtemps dans le code parce que personne ne les recherche activement, jusqu’à ce que quelqu’un le fasse. Le changement décisif n’est pas l’âge, mais le moment de la divulgation. Dès qu’un exploit fonctionnel circule, le niveau de compétence nécessaire pour les attaquants chute brutalement.

Pour les exploitants de plateformes de conteneurs, cela modifie l’urgence. Une faille restée théorique pendant des années devient un danger immédiat dès la publication du code. Cela s’applique particulièrement aux environnements à charge mixte, où du code peu fiable côtoie des services sensibles sur le même nœud. Dans ce cas, l’échappée de conteneur n’est plus un risque abstrait, mais le chemin direct d’une charge de travail anodine vers la prise de contrôle totale du nœud.

Ce qui protège vraiment

L’idée la plus importante est conceptuelle : le conteneur est une frontière opérationnelle, pas une barrière de sécurité infranchissable contre les failles du noyau. Celui qui l’accepte construit une défense en couches plutôt que de s’appuyer sur une seule hypothèse. La discipline de correctifs arrive en première ligne, car face à une faille connue avec un exploit public, c’est avant tout le correctif appliqué qui protège.

S’y ajoute la restriction de ce qu’un conteneur est autorisé à faire. Un profil d’appels système strictement défini prive de nombreux exploits du noyau de leur base, car ils ne peuvent même pas atteindre le chemin vulnérable. Et lorsque des charges de travail de niveaux de confiance différents coexistent, la séparation stricte sur des nœuds dédiés est indispensable pour éviter qu’une évasion ne compromette immédiatement les voisins sensibles. Aucune de ces mesures n’est nouvelle, mais Copy Fail montre pourquoi elles doivent être combinées.

Foire aux questions

Les conteneurs sont-ils moins sûrs que les machines virtuelles ?

Ils isolent différemment. Une machine virtuelle embarque son propre noyau, tandis que les conteneurs partagent celui de l’hôte. Face aux failles du noyau, la machine virtuelle offre donc une barrière plus solide. En revanche, les conteneurs sont plus légers et plus rapides. Le bon choix dépend du niveau de confiance des charges de travail.

Un conteneur à jour protège-t-il contre Copy Fail ?

Non, car la faille se situe dans le noyau de l’hôte, pas dans l’image. L’essentiel est que le noyau de l’hôte soit corrigé. Même une image parfaitement à jour ne protège pas si le noyau sous-jacent reste vulnérable.

Que apporte seccomp contre les exploits du noyau ?

Un profil seccomp restreint les appels système qu’un conteneur peut utiliser. De nombreux exploits du noyau nécessitent certains appels système pour atteindre le chemin vulnérable. Si ceux-ci sont bloqués, l’attaque échoue, même si la faille persiste.

Pourquoi ces erreurs ne sont-elles découvertes qu’après des années ?

Parce que les recherches ciblées sont rares. Les classes d’erreurs survivent longtemps inaperçues, jusqu’à ce qu’un chercheur examine les choses de près. L’âge ne dit rien du danger. Ce n’est qu’une fois l’exploit publié qu’une faille théorique se transforme en risque aigu.

Quels environnements sont particulièrement menacés ?

Ceux qui gèrent des charges mixtes, où du code peu fiable s’exécute aux côtés de services sensibles sur le même nœud. Dans ce cas, le chemin d’une charge de travail anodine à la compromission complète du nœud est court. Isoler les charges sensibles sur des nœuds dédiés réduit considérablement ce risque.

Source de l’image d’en-tête : Pexels / panumas nikhomkhai (px:17489157)

À propos de l'auteur: Benedikt Langer

Plus d'articles de Benedikt Langer