Conteneurs : runC affecté par une grave vulnérabilité

Des chercheurs en sécurité de la communauté Linux viennent de lever le voile sur une vulnérabilité affectant le runtime RunC utilisé par Docker et Kubernetes. Celle-ci pourrait être exploitée par un attaquant pour forcer l’exécution de code avec les privilèges les plus élevés sur l'hôte des containers.

De quoi, potentiellement, prendre le contrôle du reste de l'infrastructure de conteneurs à des fins malveillantes. Un « mauvais scénario » pour les administrateurs et exploitants de tels environnements, relève Red Hat, dans un billet de blog. Et de souligner, surtout, que « ce n’est pas la première faille majeure dans un runtime de conteneurs » et « à mesure que les déploiements de conteneurs et l’intérêt pour les technologies associées progressent, il est peu probable que ce soit la dernière ». De quoi poser la question des pratiques des utilisateurs de conteneurs.

L'utilitaire RunC joue un rôle essentiel et il faudra donc du temps et de la planification pour déployer des correctifs dans les grands environnements. Les mises à jour peuvent être facilement appliquées aux applications Web sans état, sans provoquer d’interruption notable. La situation est différente pour les traitements à états, mais ils restent encore relativement rares en production sur les containers.

Entre-temps, les utilisateurs peuvent se protéger grâce à certaines pratiques de référence bien documentées et relevant souvent du bon sens, comme le fait de ne pas télécharger et exécuter des images de conteneurs provenant de sources non vérifiées.

Scott McCarty, chef de produits conteneurs chez Red Hat, relève ainsi que l’exploitation de la vulnérabilité nécessite le dépôt d’une charge malveillante dans l'image d’un container, puis le téléchargement et l’exécution de celle-ci. Dès lors, « si vous faites déjà des choses telles qu’extraire des images de conteneurs d'une source digne de confiance... vous êtes probablement encore en sécurité ».

Mais Gary Chen, analyste chez IDC estime que les développeurs qui n'ont pas d'expertise en sécurité informatique ou qui sont soumis à des contraintes de temps pourraient toutefois télécharger ce code sans le savoir. Et, « dans le pire des cas, vous pourriez aussi avoir une malveillance interne ».

Des utilitaires tels que Docker Bench for Security, Notary ou encore Cilium et Sysdig Falco devraient permettre de détecter du code d’exploitation de la vulnérabilité. Red Hat recommande d'appliquer les règles SELinux au sein du système d'exploitation hôte pour bloquer les comportements non autorisés de conteneurs compromis.

Mais il y a plus. Des outils de sécurité dédiés aux conteneurs, tels que ceux d’Aqua, de Twistlock ou encore de NeuVector peuvent bloquer le comportement anormal des applications et le trafic réseau. De quoi limiter l’impact de l’exploitation réussie de la vulnérabilité, comme les deux premiers éditeurs l’expliquent dans des billets de blog. Kubernetes propose également des recommandations pour limiter l’étendue du risque. D'autres projets open source qui utilisent des machines virtuelles dépouillées pour isoler les containers des hôtes, tels que gVisor, Kata Containers et Amazon Firecracker, sont également destinés à traiter les exploits potentiels.

Figo.io, une jeune pousse fintech de Hambourg, en Allemagne, part du postulat selon lequel des vulnérabilités aussi graves que CVE-2019-5736 peuvent être présentes à tous les niveaux de la pile logicielle et mise sur la défense en profondeur. Lutz Behnke, son ingénieur sécurité plateforme, explique ainsi qu’en plus d'appliquer rigoureusement des permissions minimales pour chaque tâche, le concept du moindre privilège, « nous utilisons les règles de NeuVector pour appliquer des restrictions aux processus qui sont exécutés dans chaque conteneur et aux utilisateurs qui les lancent. Ces restrictions peuvent déclencher des alarmes ou même bloquer une exécution, selon la criticité du conteneur considéré ».

Au final, pour Gary Chen, cette vulnérabilité de RunC devra pousser les entreprises à penser la sécurité des conteneurs en couches multiples. Car « supposons que l'isolement du container puisse être cassé. Comment allez-vous contenir cela ? »