La vulnérabilité Linux « Dirty Pipe » et vos applications conteneurisées (CVE-2022-0847)

Qu’est-ce que la vulnérabilité « Dirty Pipe » ? (CVE-2022-0847)

Récemment, CVE-2022-0847 a été créée pour décrire une faille du noyau Linux qui peut être exploitée afin de permettre à n’importe quel processus de modifier des fichiers, quels que soient leurs paramètres d’autorisation ou leur propriétaire. La communauté de la sécurité a baptisé cette vulnérabilité « Dirty Pipe » en raison de sa similarité avec « Dirty COW », une vulnérabilité d’élévation de privilèges signalée dans CVE-2016-5195, et parce que la faille se trouve dans l’implémentation des tubes du noyau. La base de données des vulnérabilités Snyk Intel contient plusieurs références à cette vulnérabilité si vous souhaitez approfondir le sujet.

Dans cet article, nous abordons les risques auxquels vos charges de travail conteneurisées sont exposées et examinons comment un acteur malveillant peut modifier le contenu des images de conteneurs et d’autres fichiers normalement en lecture seule, quels que soient son UID et les permissions du système de fichiers.

Commençons par voir ce que vous pouvez faire dès maintenant pour protéger vos systèmes contre Dirty Pipe.

En bref : mettez à niveau vos hôtes Linux

La seule solution connue à cette vulnérabilité consiste à mettre à niveau vos hôtes Linux vers l’une des versions du noyau suivantes :

• 5.16.11

• 5.15.25

• 5.10.102

Il n’existe aucune autre mesure d’atténuation permettant de protéger vos systèmes si un acteur malveillant accède à votre environnement.

L’impact de Dirty Pipe sur vos images de conteneurs

Les images de conteneurs en bref

Une image de conteneur se compose essentiellement d’un ensemble de couches superposées. Au démarrage d’un conteneur, le moteur d’exécution (Docker, containerD, cri-O, etc.) fusionne ces couches et présente le résultat au processus sous la forme d’un système de fichiers. Ces couches sont toujours en lecture seule ; toute modification est effectuée dans une couche en lecture-écriture créée spécifiquement pour chaque instance de conteneur selon le modèle copy-on-write (COW). Cette couche en lecture-écriture est éphémère : elle est détruite lorsque le conteneur est supprimé du système. Il est également possible de l’omettre en démarrant le conteneur en lecture seule, ce qui le rend effectivement immuable.

Il est généralement conseillé de faire exécuter les processus de vos conteneurs par des utilisateurs non privilégiés et de définir leurs systèmes de fichiers racine en lecture seule. Ces mesures compliquent considérablement l’exploitation de vulnérabilités applicatives par un acteur malveillant, car elles rendent plus difficile l’ajout de son propre code ou de scripts au système de fichiers du conteneur. Consultez notre guide sur la sécurité des conteneurs pour découvrir d’autres bonnes pratiques.

Exploitation de Dirty Pipe dans un conteneur

Le fonctionnement détaillé de la vulnérabilité Dirty Pipe dépasse le cadre de cet article — consultez le billet de blog consacré à sa découverte pour en connaître tous les détails —, mais, en résumé, quelques étapes assez simples permettent de modifier le contenu de presque n’importe quel fichier, même si ses permissions et/ou son propriétaire sont censés l’empêcher. Par exemple, à l’aide du code de preuve de concept write_anything de l’article cité ci-dessus, nous allons créer une image à l’aide de ce Dockerfile :

Nous la lançons ensuite en mode lecture seule et utilisons l’exécutable write_anything pour modifier /etc/passwd.

Cela n’aurait pas dû être possible, car le fichier est en lecture seule, appartient à root et se trouve sur un système de fichiers racine en lecture seule.

Ensuite, arrêtons et supprimons ce conteneur, démarrons-en un nouveau, puis examinons /etc/passwd dans ce nouveau conteneur.

La modification du fichier a persisté, car le processus du conteneur précédent a modifié le contenu réel de la couche de l’image, pourtant en lecture seule sur le système hôte. Cette modification persistera sur cet hôte jusqu’à la suppression et/ou au remplacement de l’image.

Couche d’image de bas niveau avant l’exécution de l’attaque

Couche d’image de bas niveau après l’exécution de l’attaque

De fait, si plusieurs conteneurs s’exécutent sur le même hôte, cette modification peut être immédiatement visible par tous les conteneurs qui partagent cette couche d’image de base (à l’exception de ceux qui ont déjà modifié le même fichier dans leur propre couche en lecture-écriture).

Trois conteneurs surveillent leurs fichiers /etc/passwd avec watch, tandis qu’un quatrième conteneur exécute l’attaque write_anywhere.

Tous vos volumes montés depuis l’hôte sont à la merci de Dirty Pipe

Vous avez peut-être entendu dire que monter des volumes de l’hôte (également appelés montages liés) dans vos conteneurs est une mauvaise pratique. En temps normal, ce conseil s’explique par le fait qu’une simple erreur de configuration peut accorder au conteneur un accès non prévu permettant de modifier des fichiers sur l’hôte. Dirty Pipe aggrave le problème : les volumes montés depuis l’hôte sont exposés à cet exploit, même s’ils ont été montés avec l’indicateur :ro.

Élévation de privilèges via Dirty Pipe

L’un des exemples de preuve de concept de l’exploit qui circulent utilise cette faille pour obtenir des privilèges élevés en modifiant un binaire existant avec le bit suid activé, afin de contourner les protections habituelles. Ce problème n’est pas propre aux conteneurs, mais l’exploit peut être utilisé à l’intérieur de vos conteneurs. Par exemple, un attaquant pourrait exploiter une vulnérabilité d’exécution de code à distance (RCE) dans une application, puis injecter ce code POC pour obtenir les droits root dans votre conteneur. Il contournerait ainsi les paramètres de conteneur et/ou Kubernetes destinés à limiter ce type de comportement.

Existe-t-il des mesures d’atténuation ?

Comme indiqué plus haut, la mise à niveau de vos systèmes hôtes est le seul moyen connu de protéger vos systèmes contre cette vulnérabilité. Les mesures d’atténuation des moteurs de conteneurs et de Kubernetes opèrent à un niveau trop élevé pour protéger efficacement contre un exploit du noyau de ce type.

Ne suffit-il pas de mettre à jour nos images de base ?

Malheureusement, non. La faille ne se trouve pas dans le système de fichiers des images de base, mais dans le noyau des serveurs hôtes, partagé par tous les conteneurs en cours d’exécution. Vous pouvez le constater en exécutant uname -a dans plusieurs conteneurs utilisant des images de base différentes : ils indiqueront tous la version du noyau de l’hôte.

Qu’en est-il de SecurityContext dans Kubernetes ?

Les paramètres SecurityContext de Kubernetes, tels que readonlyRootFilesystem:true, runAsNonRoot:true, runAsUser: et AllowPrivilegeEscalation:false, sont tous inefficaces, car n’importe quel utilisateur peut exploiter cette vulnérabilité et contourner ces paramètres.

Cela ne signifie pas pour autant que vous ne devriez pas utiliser ces paramètres. Au contraire, ils illustrent parfaitement la défense en profondeur et protègent vos clusters contre de nombreux autres types d’attaques.

Nous proposons d’ailleurs une fiche pratique sur la sécurité Kubernetes qui présente les paramètres SecurityContext et explique pourquoi les utiliser pour renforcer la sécurité de vos déploiements d’applications Kubernetes. Vous pouvez également analyser vos manifestes Kubernetes avec les outils d’analyse IaC gratuits de Snyk pour détecter et corriger des erreurs de configuration comme celles-ci. Cliquez sur le lien ci-dessous pour commencer dès aujourd’hui.

Pour conclure

Si ce n’est pas déjà fait, mettez immédiatement vos hôtes à jour. Et si les sujets abordés ci-dessus ont éveillé votre intérêt, consultez les ressources suivantes pour approfondir le sujet.

• Blog CM4All : Article sur la découverte de la vulnérabilité Dirty Pipe

• Blog Snyk : Découvrez les détails de la création d’images, des couches et de l’analyse des vulnérabilités des conteneurs

• Fiche pratique Snyk : 10 paramètres SecurityContext de Kubernetes à connaître

• ArsTechnica : Linux touché par sa vulnérabilité la plus critique depuis des années