- CVE-2024-1086 dans
nf_tablesdu noyau Linux provoque une double libération desk_buffen raison d’un échec de validation des entrées de verdict Netfilter, et peut conduire, sous certaines conditions, à une élévation de privilèges locale - Le déroulement de l’attaque consiste à faire en sorte qu’un skb libéré pendant le traitement
NF_DROPcontinue d’être traité comme s’il s’agissait deNF_ACCEPT, ce qui mène à une nouvelle libération du même objet dans un chemin ultérieur - Le PoC a été validé sur KernelCTF mitigation, Debian, Ubuntu et des noyaux vanilla ; au minimum, la plage v5.14.21 à v6.6.14 est concernée selon la kconfig, et un correctif a été diffusé dans les branches stable en février 2024
- Le point clé est Dirty Pagedirectory, une méthode KSMA purement orientée données qui attribue en double des pages PTE et PMD à la même page physique afin d’accéder à des adresses physiques arbitraires uniquement via des lectures/écritures depuis l’espace utilisateur
- La recherche du KASLR physique, le contournement de
modprobe_path, l’exécution sans fichier et la connexion de descripteurs de fichiers pour sortir des namespaces sont combinés, ce qui en fait un cas pratique de LPE visant à la fois la gestion mémoire du noyau et le sous-système réseau
Conditions de vulnérabilité et périmètre d’impact
- Le bug de
nf_tablesest enregistré sous CVE-2024-1086 ; son cœur est un défaut de validation des entrées qui autorise une erreur de drop positive dans le traitement des verdicts de Netfilter - L’exploitation nécessite les conditions suivantes
nf_tablesdoit être activé- les namespaces utilisateur non privilégiés doivent être activés
- Dans les grandes distributions comme Debian et Ubuntu, le fait que ce réglage soit activé par défaut constitue une condition préalable à l’attaque
- D’après les tests, les branches stable
linux-5.15.y,linux-6.1.yetlinux-6.6.ysont concernées, etlinux-6.7.1pourrait également l’être - En février 2024, un correctif du bug a été diffusé dans les branches stable
- Le code source du PoC est publié dans le dépôt PoC CVE-2024-1086
Flux de code produisant la double libération
- Un verdict Netfilter est une valeur qui détermine s’il faut abandonner un paquet, l’accepter, l’envoyer en file d’attente, etc.
- Le flux vulnérable commence par le fait que
nft_verdict_init()ne limite pas suffisamment la valeur de verdict fournie par l’utilisateur, ce qui permettait de définir une valeur ressemblant àNF_DROPtout en ayant une erreur de drop positive nf_hook_slow()examine les bits de poids faible du verdict et, s’il l’interprète commeNF_DROP, libère d’abord le skb aveckfree_skb_reason()- Ensuite, si le résultat de
NF_DROP_GETERR()correspond à une valeur équivalente àNF_ACCEPT, l’appelant considère que le paquet a été accepté et poursuit le traitement - Résultat : un skb déjà libéré est à nouveau libéré dans un chemin ultérieur, créant un primitive de double-free
Objets corrompus et mode de traitement des paquets
- La double libération affecte
struct sk_buffdansskbuff_head_cacheainsi que l’objetsk_buff->head sk_buff->headcontient le contenu réel du paquet et, selon la taille du paquet IPv4, peut être alloué depuiskmalloc-256jusqu’à une page d’ordre 4 du buddy allocator- Le PoC est conçu pour utiliser de gros paquets IP afin d’emprunter le chemin du buddy allocator plutôt que celui du slab allocator
- La file de fragmentation IPv4 est utilisée pour retarder la seconde libération du skb ou la déclencher au moment voulu
- Si des champs skb corrompus sont utilisés dans le chemin des paquets, le noyau peut paniquer ; l’exploit évite donc les piles TCP/UDP et exploite un chemin d’erreur spécifique aux fragments IP
Périmètre de test et taux de réussite
- Plusieurs versions et configurations de noyau ont été testées dans des environnements vanilla, KernelCTF, Debian et Ubuntu
- Les cas de réussite incluent les environnements suivants
- Linux v5.14.21, v5.15.148, v5.16.20, v5.17.15, v5.18.19, v5.19.17, v6.0.19
- Linux v6.1.55 de KernelCTF Mitigation v3
- Linux v6.1.69 de Debian Bookworm 6.1.0-17
- Linux v6.1.72 de KernelCTF LTS
- Ubuntu Jammy v6.2.0-37
- Linux v6.2.16, v6.3.13
- Les cas d’échec incluent v5.4.270, v5.10.209, v6.4.16, Ubuntu Jammy v6.5.0-15, v6.5.13, v6.6.14, v6.7.1, etc.
- Certains échecs après v6.4.0 sont liés à la détection
bad_page()due àCONFIG_INIT_ON_ALLOC_DEFAULT_ON=y - Dans l’environnement v6.4.16, le taux de réussite était de 99,4 %, descendant dans certains cas à 93,0 %, avec dans chaque cas un échantillon de n=1000
Méthode de correction
- Le premier correctif proposé aurait pu introduire un breaking change au milieu de la pile Netfilter
- Le correctif du mainteneur de Netfilter limite plus strictement, au niveau de l’API, les verdicts provenant des entrées utilisateur
- Le patch consiste à rejeter les paramètres de verdict DROP/QUEUE provenant de l’espace utilisateur
- Selon la description de la CVE,
nft_verdict_init()autorisait des valeurs positives comme erreur de drop dans un verdict de hook, etnf_hook_slow()pouvait créer une double libération lorsqueNF_DROPetNF_ACCEPTse chevauchaient - Le patch de correction est consultable ici : [PATCH nf] netfilter: nf_tables: reject QUEUE/DROP verdict parameters.
Dirty Pagedirectory et accès arbitraire à la mémoire physique
- La technique centrale du PoC est Dirty Pagedirectory, une variante de la technique existante Dirty Pagetable
- L’idée principale consiste à attribuer en double des pages PTE et PMD à la même page physique
- Lorsqu’une valeur ressemblant à une entrée PTE est écrite dans une région d’adresses virtuelles, une autre région d’adresses virtuelles l’interprète comme une entrée de table de pages et mappe la page physique indiquée
- Cette méthode fonctionne comme une kernel-space mirroring attack permettant de définir des adresses physiques arbitraires et des indicateurs de permissions, puis d’y accéder, uniquement via des lectures/écritures d’adresses en espace utilisateur
- Elle sert à contourner des protections comme le virtual KASLR, KPTI, SMAP, SMEP ou
CONFIG_STATIC_USERMODEHELPER
Manipulation de l’allocateur de pages
- L’allocation de pages du noyau implique le slab allocator, le buddy allocator et le PCP allocator
- Pour les grandes tailles, la tête skb utilise des pages d’ordre 4 du buddy allocator, tandis que les pages PTE/PMD sont des pages d’ordre 0 ; elles ne s’emboîtent donc pas directement
- Pour résoudre ce problème, deux méthodes de conversion de pages sont utilisées
- Vidage des listes PCP : placer une page d’ordre 4 dans la freelist buddy, vider la freelist PCP d’ordre 0, puis laisser le buddy allocator la remplir à nouveau avec des pages d’ordre 0
- Race condition : exploiter une concurrence lors de la seconde libération pour insérer une page d’ordre 4 dans la freelist d’ordre 0
- Le vidage des listes PCP est la méthode la plus simple, stable et rapide
- La méthode par race condition avait été utilisée dans les premiers exploits KernelCTF, mais elle est considérée comme obsolète car elle dépend d’environnements à forte latence de TTY série, comme les VM QEMU
Contournement de KernelCTF mitigation
- Dans l’environnement KernelCTF mitigation, la protection qu’il fallait contourner activement était le contrôle de corruption de freelist de
sk_buff - Comme
skbuff_head_cache->offset == 0x70, le pointeur next de la freelist chevaucheskb->len - Après la première libération du skb,
skb->lenest partiellement écrasé par le pointeur de freelist ; puis, pendant l’analyse du paquet, cette valeur peut changer et déclencher le contrôle de corruption - La détection est contournée en libérant un skb normal supplémentaire par-dessus le skb corrompu afin d’écraser la tête de freelist
- Les développeurs de KernelCTF estiment que vérifier le pointeur next de la tête de freelist au moment de la libération permettrait d’atténuer ce contournement
Flush du TLB et recherche du KASLR physique
- Lorsque Dirty Pagedirectory modifie les tables de pages de manière inattendue, d’anciennes informations de traduction peuvent rester dans le cache TLB du CPU
- Le TLB est flushé depuis l’espace utilisateur en lançant un
fork(), puis en faisant exécutermunmap()au processus enfant avant qu’il ne s’endorme - Cette méthode a été confirmée comme fonctionnant à 100 % sur des CPU AMD et dans des VM QEMU
- La recherche du KASLR physique réduit l’espace de recherche en exploitant le fait que l’adresse physique de base du noyau est alignée sur
CONFIG_PHYSICAL_STARTouCONFIG_PHYSICAL_ALIGN - En supposant 8 Gio de mémoire physique et un alignement de 16 Mio, il y a 512 candidats ; le script get-sig génère une signature de base du noyau pour les identifier
modprobe_path et obtention d’un shell root
- Après avoir obtenu des lectures/écritures arbitraires en mémoire physique, le PoC scanne une plage d’environ 80 Mio après la base du noyau pour trouver
modprobe_path - Dans une configuration classique, il recherche le motif
"/sbin/modprobe"suivi d’un padding nul, puis vérifie la variable réelle en observant la répercussion dans/proc/sys/kernel/modprobe - Si
CONFIG_STATIC_USERMODEHELPERest activé, il cible la chaîne"/sbin/usermode-helper" - Pour obtenir un shell root,
modprobe_pathou la chaîne du static usermode helper est remplacé par un chemin memfd de la forme/proc/<pid>/fd/<fd> - Le script d’élévation de privilèges connecte les descripteurs de fichiers de l’exploit au stdin/stdout du shell afin de fonctionner aussi bien avec un terminal local qu’avec un reverse shell
Exécution sans fichier et composition du PoC
- Le PoC prend en charge l’exécution sans fichier
- Si Perl est présent sur la cible,
memfd_create()permet de charger le binaire de l’exploit en mémoire et de l’exécuter via/proc/$$/fd/<fd> - Les dépendances de compilation sont
libnftnl-devetlibmnl-dev - La compilation statique pour KernelCTF utilisait
musl-gcc, afin d’éviter les problèmes de liaison statique avec glibc et d’opcodes AVX512 dans QEMU - Le code source de l’exploit est réparti sur plusieurs fichiers et, comme il vise un binaire autonome, il choisit de crasher/quitter en cas d’erreur plutôt que de renvoyer un code d’erreur
Stabilité et limites
- Comme l’état des pagetables du processus d’exploitation peut devenir instable, les processus enfants ne sont pas terminés après succès ou échec, mais laissés en sommeil afin de réduire l’instabilité du noyau
- L’activité réseau peut introduire du bruit dans la freelist skb et affecter la stabilité
- Dans des environnements SSH ou reverse shell, la sortie stdout autour du moment de la double libération est réduite afin de minimiser les allocations/libérations skb dues au réseau
- Lors de certains tests matériels, le système a crashé après quelques secondes ; comme les frames WiFi utilisent aussi des skb, l’activité WiFi a pu avoir un impact
- La désactivation de l’adaptateur WiFi dans le BIOS a permis à l’exploit de fonctionner correctement dans cet environnement
Conclusions tirées du travail de recherche
- Le PoC a été affiné avec pour objectifs une large compatibilité, une grande stabilité et une exécution discrète
- À deux mois de développement se sont ajoutés deux mois consacrés à l’amélioration de la stabilité et de la compatibilité
- L’exploit lui-même ne dépend pas fortement du comportement du slab allocator et repose surtout sur des fonctionnalités largement activées, comme le sous-système IPv4 et la mémoire virtuelle
- Le bug initial nécessite un user namespace non privilégié et nftables, mais des techniques comme Dirty Pagedirectory et le vidage PCP peuvent aussi être utilisées dans d’autres exploits réels
- Ce travail reste un exemple d’analyse conjointe du sous-système réseau et du sous-système de gestion mémoire du noyau Linux
1 commentaires
Avis sur Hacker News
J’ai publié aujourd’hui un exploit de preuve de concept pour CVE-2024-1086, qui fonctionne notamment sur Debian et Ubuntu.
Les versions affectées sont les noyaux Linux v5.14 à v6.6 ; la prise en charge de v6.4 à v6.6 dépend du paramètre noyau
CONFIG_INIT_ON_ALLOC_DEFAULT_ON.Ce bug a été corrigé en février 2024, donc mettez à jour vos machines Linux.
https://github.com/Notselwyn/CVE-2024-1086/blob/main/src/mai...
modprobe_pathet même ajouter du bruteforce de pid à cause de l’approche sans fichier.Par exemple, j’aimerais savoir pourquoi il n’a pas choisi de patcher le
.textdu noyau avec un court shellcode pour devenir root et sortir de l’espace de noms.Elle précise toutefois que les branches corrigées
v5.15.149>,v6.1.76>etv6.6.15>sont exclues.Le correctif contient cette phrase : « This reverts commit e0abdadcc6e1. [...] Its not clear to me why this commit was made. »
Je me demande si quelqu’un a retrouvé le contexte historique de ce commit.
[1] https://lore.kernel.org/all/20240120215012.129529-1-fw@strle...
J’ai fouillé les anciennes listes netdev sans rien trouver ; il a aussi pu s’agir d’un patch envoyé directement au committer, Pablo Neira Ayuso.
L’auteur initial était Patrick McHardy, devenu depuis une personne à éviter, et à moins que Pablo ne s’en souvienne ou ne retrouve quelque chose dans ses mails, le cas d’usage exact semble difficile à établir avec une enquête de base.
netfilter: nf_tables: accept QUEUE/DROP verdict parameters; il permet à l’espace utilisateur de spécifier un numéro de file ou un code errno pour les verdictsQUEUEetDROP.Cet article est aussi très impressionnant du point de vue de la rédaction en sécurité.
Quand on écrit un blog sécurité, on se demande toujours « combien de contexte et de connaissances préalables faut-il supposer ? » ; trouver un équilibre entre accessibilité et faisabilité est difficile.
J’ai beaucoup apprécié le fait qu’il définisse d’abord le public visé et fournisse suffisamment de contexte, et je l’ai ajouté à mes favoris pour le donner comme ressource aux aspirants chercheurs que je rencontre chaque année.
Cet exploit dépend de l’accès aux espaces de noms utilisateur non privilégiés :
sysctl kernel.unprivileged_userns_clone = 1C’est la valeur par défaut des noyaux Debian/Ubuntu et Arch Linux ; si vous n’avez pas besoin d’exécuter des commandes Docker sans sudo, par exemple, mieux vaut la désactiver.
Le sandbox Chrome utilisé par les applications Electron ou 1Password est également concerné, et le binaire d’assistance du sandbox peut aussi fonctionner comme programme setuid.
Il ne serait pas surprenant que Proton commence aussi à utiliser les espaces de noms utilisateur à l’avenir ; sur un Linux de bureau classique, il vaut donc peut-être mieux ne pas le désactiver.
Sur des serveurs ou des Linux spécialement renforcés, le désactiver est souvent raisonnable.
Le problème, c’est que pour que les conteneurs « fonctionnent tout simplement », il faut une multitude de bidouilles côté réseau, et l’un des principaux arguments de vente de Docker revient presque à prendre en charge ces bidouilles dangereuses à votre place.
Au final, toute solution de conteneurs en vient à accepter ces bidouilles ; même si les fonctionnalités normales des espaces de noms réduisent l’accès, le noyau finit par ouvrir la porte à cause des bricolages réseau.
Je ne comprends pas pourquoi les espaces de noms utilisateur non privilégiés sont activés par défaut.
Même si l’exécution se fait dans un espace de noms « non privilégié », pourquoi donner par défaut aux utilisateurs la possibilité d’exécuter des choses comme iptables ou mount ?
Par exemple, Chrome utilise les espaces de noms pour implémenter son sandbox de processus, mais il installe aussi un binaire setuid-root afin de pouvoir fonctionner même sans espaces de noms non privilégiés.
Comme les binaires setuid-root sont eux-mêmes un risque de sécurité, il serait préférable à long terme que Chrome n’ait plus besoin d’en installer.
Pour cela, les espaces de noms utilisateur non privilégiés doivent toutefois être largement disponibles, et ce type de bug retarde cet avenir.
De plus, les programmes qui mettent en place un sandbox basé sur les espaces de noms, comme Chrome, utilisent souvent aussi seccomp afin d’empêcher le code à l’intérieur du sandbox d’utiliser des fonctionnalités noyau particulières comme les espaces de noms.
Sur un poste de bureau mono-utilisateur, l’intérêt d’appliquer fortement la séparation entre l’utilisateur et root est limité, et la plupart des éléments intéressants sont de toute façon accessibles depuis le compte utilisateur.
En revanche, un sandbox comme celui de Chrome est essentiel à la sécurité du poste de bureau ; sur une machine mono-utilisateur, j’aurais donc tendance à considérer que l’activation des espaces de noms utilisateur non privilégiés améliore la sécurité globale.
Un système multi-utilisateur est évidemment une autre histoire.
Sans ce genre de bugs récurrents, les espaces de noms utilisateur non privilégiés auraient été une excellente fonction de sécurité.
Par exemple, ce serait bien que l’exécution de Flatpak n’ait pas besoin de binaires setuid de l’hôte pour isoler les applications.
La plupart des valeurs par défaut ne sont pas sûres, et il faut des connaissances techniques ainsi qu’un travail de durcissement.
Le commit qui a introduit le problème : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
La structure paraît étrange : dans un
switch/caseimbriqué, le chemin par défaut contient unreturn, alors que la suite semble s’attendre à un fall-through.https://lwn.net/Articles/882397/
https://bugs.launchpad.net/bugs/cve/2024-1086
Il s’agit d’une vulnérabilité use-after-free dans le composant
netfilter: nf_tablesdu noyau Linux, permettant une élévation de privilèges locale.La fonction
nft_verdict_init()accepte des valeurs positives comme erreur de drop dans un verdict de hook ; par conséquent,nf_hook_slow()peut traiter unNF_DROPaccompagné d’une erreur de drop qui ressemble àNF_ACCEPT, ce qui peut créer une vulnérabilité de double libération.Il est recommandé de mettre à niveau vers une version postérieure à
f342de4e2f33e0e39165d8639387aa6c19dff660.Je me demande comment de tels exploits restent possibles malgré les mitigations modernes comme l’ASLR.
À l’université, dans un cours, on nous donnait plusieurs binaires à exécuter sur une version précise d’Ubuntu, et il fallait trouver puis exploiter des bugs comme des use-after-free ou des buffer overflows ; c’était vraiment difficile.
Trouver la faille est déjà difficile, mais écrire le shellcode exact permettant d’en faire quelque chose d’utile l’est encore plus.
Dans les étapes plus avancées, des mitigations comme l’ASLR et les stack canaries étaient aussi activées, et même dans un environnement étudiant contrôlé, cela semblait presque impossible.
Au final, il faut 1) découvrir une faille exploitable et 2) trouver le payload binaire exact qui fait quelque chose d’utile sans simplement faire planter le programme ; je me demande donc comment c’est possible dans le monde réel, où cela devrait être encore plus difficile.
[0] https://web.stanford.edu/class/archive/cs/cs107/cs107.1194/a...
En parallèle d’autres cours, elle ne pouvait sans doute consacrer que quelques heures à quelques jours à un bug donné.
Zerodium paie 50 000 dollars pour une élévation de privilèges locale Linux générique, ce qui permet grosso modo d’acheter 200 heures-personnes au tarif d’un développeur d’exploits expérimenté.
Autrement dit, des experts y consacrent 10 à 100 fois plus de temps qu’un étudiant débutant.
Il suffit de penser à la différence entre quelqu’un qui entre pour la première fois dans un atelier de menuiserie et un menuisier, entre un débutant en poterie et un artisan, ou entre un peintre novice et un artiste professionnel.
Et à cela s’ajoute encore un facteur 10 à 100 en temps investi.
[1] https://zerodium.com/program.html
Il existe des techniques « classiques » pour contourner la plupart des protections récentes, et lorsqu’il n’y en a pas, de nouvelles attaques ou méthodes de contournement finissent parfois par apparaître.
Par exemple, on peut consulter how2heap pour les contournements de protections du tas[0], il y a déjà eu des exemples d’exploits contournant KASLR[1], et cet exploit-ci semble utiliser la technique dirty pagetable[2].
C’est une dynamique permanente de jeu du chat et de la souris, où des mitigations sont ajoutées puis les chercheurs cherchent à les contourner.
[0] https://github.com/shellphish/how2heap
[1] https://www.willsroot.io/2022/12/entrybleed.html
[2] https://pwning.tech/nftables/#452-the-technique
Pour trouver ce genre de chose, une seule personne de la dernière catégorie suffit.
Aujourd’hui, c’est vraiment difficile, et même en désactivant les mitigations, trouver des vulnérabilités et écrire des exploits reste loin d’être facile.
Cela dit, beaucoup de personnes qui découvrent ce type de vulnérabilités travaillent en équipe, parallélisent le fuzzing, et peuvent combiner ou chaîner leurs connaissances avec d’autres exploits.
L’expertise et le talent de certains chercheurs sont impressionnants, et dans ce domaine, des années voire des décennies d’expérience ont une valeur énorme.
Mais si l’on considère que les gros bugs découverts aujourd’hui le sont par des équipes bien financées ou des acteurs étatiques, il devient plus compréhensible qu’en mobilisant beaucoup de personnes et de ressources, ils puissent contourner les mitigations existantes.
Selon Ubuntu, toutes les versions LTS sont affectées, et le problème est corrigé dans les noyaux actuellement patchés : https://ubuntu.com/security/CVE-2024-1086
Focal est corrigée dans
5.4.0-174.193, Jammy dans5.15.0-101.111, et Mantic dans6.5.0-26.26.Si vous utilisez le support étendu, Xenial et Bionic sont également concernés.
Je l’ai exécuté sur un système Debian vulnérable : il n’y a pas eu d’élévation de privilèges, mais au deuxième lancement, tout le système s’est figé.
Le premier lancement avait simplement échoué ; cela vaut donc largement la peine de prendre le temps d’appliquer le correctif.
La configuration actuelle du noyau peut être consultée dans des fichiers comme
/boot/configou/proc/config.gz.