Conteneurs et sécurité

Timothée Ravier
siosm@floss.social - tim.siosm.fr/cours - github.com/travier

5e année cycle ingénieur, filière STI
Option Sécurité des Systèmes Embarqués et du Cloud (2SEC)

2024 - 2025

Points d'attention

• Sécurité de l'hôte hébergeant les conteneurs :
  • Matériel
  • Noyau et système de base
  • Gestionnaire de conteneurs
  • Méchanismes d'isolation entre les conteneurs
• Sécurité de l'image de base d'un conteneur :
  • Distribution et intégrité
  • Distribution des secrets
• Sécurité de l'application dans le conteneur :
  • Système de base et mises à jour
  • Langage de programmation & Framework

Sécurité de l'hôte

Matériel : Co-processeurs et co-OS

• Plusieurs processeurs sur une carte mère moderne
• Plusieurs OS dans un système :
  • Intel Management Engine
  • AMD Platform Security Processor
  • Attacking SMM Memory via Intel CPU Cache Poisoning
• Modems et Baseband pour les téléphones mobiles
• Carte graphiques (GPU) : XDC2012: Graphics stack security
• TPM : ROCA vulnerability
• Cartes ethernet, Wi-Fi, fibre optique, etc.

Matériel : Co-processeurs et firmwares

• Matériel plein de logiciels : Firmwares
  • Binarly Discovers High-Impact Vulnerabilities In Firmware Impacting Millions Of Enterprise Devices
  • PixieFail: Nine vulnerabilities in Tianocore's EDK II IPv6 network stack
• Mises à jour avec Linux Vendor Firmware Service (LVFS)
• Configuration du BIOS/Firmware EFI : Recommandations de l'ANSSI
• Sécurité de la plateforme :
  • CHIPSEC: Platform Security Assessment Framework
  • https://github.com/ANSSI-FR/chipsec-check

Matériel : Nombreux éléments partagés

Attaques par canaux cachés :

• Pas d'isolation physique : matériel partagé :
  • Rowhammer
  • Reverse Engineering Intel DRAM Addressing and Exploitation
  • Cross Processor Cache Attacks
• Attaques utilisant des canaux cachés (ou détournées) :
  • temps & cache : Meltdown and Spectre
  • son : RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis
  • bruit électromagnétique : TEMPEST
  • Power LED (!) : Video-based Cryptanalysis
  • Lend Me Your Ear: Passive Remote Physical Side Channels on PCs

Noyau Linux

• Très nombreux bugs découverts à l'aide du fuzzing
• google/syzkaller: Found bugs
• Defragmenting the kernel development process

Noyau Linux

• Faille exploitable à distance : souvent réseau, très rare
• Faille locale : appels systèmes, surface d'attaque large :
  • Gestion de la mémoire : Dirty CoW
  • Gestion des caches : Dirty Pipe Linux Vulnerability: Overwriting Files in Container Images
  • Systèmes de fichiers :
    • CVE-2015-1328 : incorrect permission checks in overlayfs
    • Enforcing mount options for sysfs and proc
  • Drivers : bluetooth, ioctl (cf. Android), etc.
    • BleedingTooth: Linux Bluetooth Zero-Click Remote Code Execution
  • Réseau : netfilter, etc.

Noyau Linux et namespaces

• Cible privilégiée : point commun entre tous les conteneurs
• L'isolation fournie par les namespaces et les cgroups a encore des limites
• Cas non prévus lorsque l'on combine plusieurs namespaces
• Certaines parties du noyau n'ont pas encore été adaptées aux namespaces
• Voir les (nombreuses) présentations sur l'exploitation du noyau :
  • Linux Kernel Exploitation - Earning Its Pwnie a Vuln at a Time
  • Exploiting the Linux kernel: Measures and countermeasures

Noyau Linux : namespaces & overlayfs

• Beaucoup de vulnérabilités trouvées ces dernières années :
  • Anatomy of a user namespaces vulnerability (CVE-2013-1858)
  • CLONE_NEWUSER|CLONE_FS root exploit
  • Linux namespaces: It is possible to escape from bind mounts (CVE-2015-2925)
  • User namespaces + overlayfs = root privileges
  • CVE-2015-4176, CVE-2015-4177, CVE-2015-4178
  • CVE-2015-8660, etc. (liste non-exhaustive)
• Failles noyau donc très souvent critiques (« local root »)
• Vulnérabilité récente :
  • CVE-2023-0386: Datadog Security Labs

Noyau Linux : user namespaces

• Surface d'attaque étendue avec les user namespace
• Important de limiter les capabilities même avec les user namespace
• Exemples de vulnérabilités récentes :
  • The Discovery and Exploitation of CVE-2022-25636
  • How The Tables Have Turned: An analysis of two new Linux vulnerabilities in nf_tables
  • CVE-2022-0185, CVE-2022-0185 in Linux Kernel Can Allow Container Escape in Kubernetes

Protection du noyau Linux

Réduction de la surface d'attaque :

• Retirer des appels systèmes du noyau (dur)
• Limiter les appels systèmes disponibles : seccomp-bpf (plus facile)

Outils pour générer des filtres seccomps fins:

• Improving Linux container security with seccomp
• go2seccomp

Durcissement du noyau Linux

• « Historiquement » : PaX & grsecurity
• Les patchs ne sont plus disponibles publiquement
• Travail en cours par le Kernel Self Protection Project pour améliorer progressivement la situation upstream
• Arrivée progressive de Rust dans le noyau Linux :
  • NVMe Driver
  • Android Binder Driver
  • Apple AGX GPU driver

Durcissement distributions Linux

• Durcissement « classique » à l'aide de guides de recommandations:
  • Recommandations de sécurité relatives à un système GNU/Linux
  • Recommandations de sécurité pour l'architecture d'un système de journalisation
  • Sécurité des systèmes de virtualisation
  • Recommandations relatives à l'administration sécurisée des systèmes d'information
  • NIST Application Container Security Guide
  • Security Assurance Requirements for Linux Application Container Deployments
  • NIST Guidance on Application Container Security

Distributions Linux

• Mises à jour régulières
• Exemple de vulnérabilité récente :
  • glibc : CVE-2023-6779, Qualys Security Advisory

Outils de gestion de conteneurs

• Les outils d'infrastructure pour gérer les conteneurs font parti de la surface d'attaque
• Vulnérabilités récentes :
  • CVE-2024-21626 (Docker Security Advisory, runc upstream, Snyk)
• Historique des vulnérabilités :
  • Container CVE List
  • Container Security Site

Vulnérabilités spécifiques à LXC

• Vulnérabilités historiques :
  • à la création d'un conteneur : LXC CVE-2013-6441
  • dans les templates de création de conteneurs : Security issue in LXC (CVE-2015-1335)

Vulnérabilités spécifiques à Docker

Sécurité ?

« Docker is about running random code downloaded from the Internet and running it as root. »

Vulnérabilités spécifiques à Docker

• Démon dockerd et containerd tournent en root
• Opération sur des images qui ne sont pas de confiance : Before you initiate a “docker pull”
• Vulnérabilités historiques :
  • Docker 1.3.2 - Security Advisory
  • Docker 1.6.1 - Security Advisory
• Nouvelle architecture depuis la version 1.11.0

Spécificités Docker

• Accès au démon docker root
• Restreindre impérativement l'accès au démon docker : Why we don't let non-root users run Docker in CentOS, Fedora, or RHEL
• Guides pour utiliser Docker correctement : Docker security
• Applicable aussi à Podman si le mode démon est configuré

Isolation : SELinux

• Contenir les conteneurs à l'aide des catégories (MCS)
• Tous les conteneurs utilisent le même type (même accès)
• Associe à l'exécution un ensemble de catégories à chaque conteneur
• SELinux garantie qu'il ne peut pas y avoir d'intéraction entre les conteneurs si leur ensemble de catégories sont distincts
• Supporté par Docker et Podman
• Limite la portée d'une grande partie des vulnérabilités (ex. CVE-2016-9962)

Isolation : AppArmor

• AppArmor supporté par Docker et Podman :
  • https://docs.docker.com/engine/security/apparmor/
  • https://cloud.google.com/container-optimized-os/docs/how-to/secure-apparmor

Isolation : Virtualisation matérielle

• Isolation supplémentaire à l'aide de la virtulisation matérielle

• Kata Containers

  • Hyperviseurs: QEMU, Cloud-Hypervisor and Firecracker
  • Learn about Red Hat OpenShift sandboxed containers

• Aussi gVisor et Nabla Containers

  • gVisor Networking Security

• Confidential Containers

  • Combine virtualisation, attestation et chiffrement (mémoire et disques)
  • Intel TDX, AMD SEV and IBM Z Secure Execution
  • What is the Confidential Containers project?

Sécurité du conteneur et de son image de base

Sécurité du conteneur

• Restriction des permissions :
  • Utiliser un utilisateur non privilégié
  • Limiter les capabilities
  • Ne pas autoriser l'élévation des priviléges (NoNewPrivileges)
  • Appliquer un filtre seccomp-bpf strict
• Image du conteneur en lecture seule (RO)
• Stockage persistent externe (par ex. volumes Docker) pour :
  • la configuration en lecture seule
  • les données en lecture / écriture

Sécurité de l'image de conteneur

• Contrôle de l'intégrité du conteneur :

  • stockage, transport sur le réseau, vérification avant exécution

• Signer les images de conteneurs :

  • sigstore
  • Signer les images de conteneurs avec cosign
  • Fonctionnement avec gestion de clés ou avec clés éphémères (keyless)

• Typo-squatting et multi-registre :

  • Container Image Squatting in a Multi-Registry World

Image de conteneur : Distribution et gestion des secrets ?

• Considérer une image de conteneur comme publique
• Ne pas inclure de secrets dans une image de conteneur
  • Sinon, établir un control d'accès fort
• Utilisation de variables d'environnement ou de volumes
• Récupération dynamique des secrets : HashiCorp Vault

Sécurité de l'application

Sécurité des applications : système de base

• Conteneurs sont souvent créés à partir d'un système de base
• La taille n'est pas toujours un facteur de décision (même si l'on cherche souvent à la réduire le plus possible)
• Choisir un système de base avec des bonnes propriétés de sécurité et correctement supporté :
  • Attention aux images basées sur Alpine :
    • Compatibilité avec musl libc
    • Gestionnaire de paquet spécifique (apk): Remote Code Execution in Alpine Linux
  • Les distributions standard (Debian, Ubuntu, Fedora, Red Hat & CentOS Stream) restent une valeur sûre.

Sécurité des applications : mises à jour

• Conteneur énorme binaire statique
• Absolument prévoir un cycle de mise à jour
• Intégration et déploiement continue (CI/CD)
• Beaucoup d'images proposés sur le Registry ne sont pas à jour ou malveillantes
  • Analysis on Docker Hub malicious images: Attacks through public container images

Sécurité des applications : scanneurs de vulnérabilités

• Outils pour vérifier qu'une image ne contient pas de vulnérabilité déjà connue :
  • Clair, intégré dans Quay.io
  • Aqua Security Trivy
  • Open Scap : Security compliance of RHEL7 Docker containers

Supply Chain et licences

• Attention au respect des licences open source
• Nombreux outils de gestion de la Supply Chain
• Suivit des licences et des vulnérabilités trouvées dans les bibliothèques utilisées par les applications
• Software Supply Chain, Software Bill of Materials (SBOM)

Sécurité des applications : langages

• Une application vulnérable sera toujours vulnérable dans un conteneur
• Utiliser des langages de programmation et des « frameworks » avec des propriétés intéressantes en terme de sécurité :
  • Rust
  • Go, Kotlin
  • Haskell, OCaml, Elixir, Erlang
  • Java, Python, Javascript, Typescript

Suite

Sécurité de la virtualisation