Deux vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 r\u00e9v\u00e9l\u00e9es dans le noyau Linux, similaires \u00e0 la vuln\u00e9rabilit\u00e9 Copy Fail d\u00e9voil\u00e9e il y a quelques jours, mais se manifestant dans d'autres sous-syst\u00e8mes \u2014 xfrm-ESP et RxRPC. La s\u00e9rie de vuln\u00e9rabilit\u00e9s a \u00e9t\u00e9 nomm\u00e9e Dirty Frag (on trouve aussi le terme Copy Fail 2). Ces vuln\u00e9rabilit\u00e9s permettent \u00e0 un utilisateur non privil\u00e9gi\u00e9 d'obtenir des droits root en \u00e9crasant des donn\u00e9es de processus dans le cache m\u00e9moire. Un exploit est disponible, fonctionnant sur toutes les distributions Linux r\u00e9centes. Les d\u00e9tails sur la vuln\u00e9rabilit\u00e9 ont \u00e9t\u00e9 divulgu\u00e9s avant la publication des correctifs, mais un contournement est possible pour bloquer le probl\u00e8me. <\/p>\n
Dirty Frag couvre deux vuln\u00e9rabilit\u00e9s distinctes : la premi\u00e8re dans le module xfrm-ESP, utilis\u00e9 pour acc\u00e9l\u00e9rer les op\u00e9rations de cryptage en IPsec en utilisant le protocole ESP (Encapsulating Security Payload), et la seconde dans le pilote RxRPC, qui impl\u00e9mente la famille de sockets AF_RXRPC et le protocole RPC \u00e9ponyme fonctionnant au-dessus de UDP. Chacune de ces vuln\u00e9rabilit\u00e9s permet individuellement d'acc\u00e9der aux droits root. La vuln\u00e9rabilit\u00e9 dans xfrm-ESP existe dans le noyau Linux depuis janvier 2017, tandis que celle dans RxRPC est pr\u00e9sente depuis juin 2023. Les deux probl\u00e8mes sont caus\u00e9s par des optimisations permettant l'\u00e9criture directe dans le cache m\u00e9moire. <\/p>\n
Pour exploiter la vuln\u00e9rabilit\u00e9 dans xfrm-ESP, l'utilisateur doit avoir des droits pour cr\u00e9er des espaces de noms, et pour exploiter la vuln\u00e9rabilit\u00e9 dans RxRPC, il doit \u00eatre en mesure de charger le module noyau rxrpc.ko. Par exemple, dans Ubuntu, les r\u00e8gles d'AppArmor interdisent \u00e0 un utilisateur non privil\u00e9gi\u00e9 de cr\u00e9er des espaces de noms, mais le module rxrpc.ko est charg\u00e9 par d\u00e9faut. Dans certaines distributions, le module rxrpc.ko est absent, mais la cr\u00e9ation d'espaces de noms n'est pas bloqu\u00e9e. Le chercheur ayant identifi\u00e9 le probl\u00e8me a pr\u00e9par\u00e9 un exploit combin\u00e9 capable d'attaquer le syst\u00e8me via les deux vuln\u00e9rabilit\u00e9s, ce qui permet d'exploiter le probl\u00e8me dans toutes les grandes distributions. L'exploitation a \u00e9t\u00e9 confirm\u00e9e dans Ubuntu 24.04.4 avec le noyau 6.17.0-23, RHEL 10.1 avec le noyau 6.12.0-124.49.1, openSUSE Tumbleweed avec le noyau 7.0.2-1, CentOS Stream 10 avec le noyau 6.12.0-224, AlmaLinux 10 avec le noyau 6.12.0-124.52.3 et Fedora 44 avec le noyau 6.19.14-300. <\/p>\n
Tout comme dans le cas de la vuln\u00e9rabilit\u00e9 Copy Fail, les probl\u00e8mes rencontr\u00e9s dans xfrm-ESP et RxRPC sont dus \u00e0 l'ex\u00e9cution d'une d\u00e9cryption des donn\u00e9es sur place, en utilisant la fonction splice(), qui transf\u00e8re des donn\u00e9es entre des descripteurs de fichiers et des canaux (pipe) sans duplication, en passant par des r\u00e9f\u00e9rences aux \u00e9l\u00e9ments dans le cache de pages. Les d\u00e9calages pour l'op\u00e9ration d'\u00e9criture \u00e9taient calcul\u00e9s sans v\u00e9rifications appropri\u00e9es, tenant compte de l'utilisation de r\u00e9f\u00e9rence directe sur les \u00e9l\u00e9ments dans le cache de pages, ce qui permettait, par l'envoi de requ\u00eates sp\u00e9cialement con\u00e7ues, de r\u00e9\u00e9crire 4 octets \u00e0 un d\u00e9calage choisi et de modifier le contenu dans le cache de pages de n'importe quel fichier. <\/p>\n
Toutes les op\u00e9rations de lecture de fichiers renvoient d'abord le contenu du cache m\u00e9moire. En cas de modification des donn\u00e9es dans le cache m\u00e9moire, les op\u00e9rations de lecture de fichier renverront des informations qui ne sont pas r\u00e9ellement stock\u00e9es sur le stockage, mais des donn\u00e9es falsifi\u00e9es. L'exploitation de la vuln\u00e9rabilit\u00e9 consiste \u00e0 modifier le cache m\u00e9moire pour un fichier ex\u00e9cutable avec le drapeau suid root. Par exemple, pour obtenir les droits root, il est possible de lire le fichier ex\u00e9cutable \/usr\/bin\/su pour le placer dans le cache m\u00e9moire, puis de substituer son propre code dans le contenu charg\u00e9 dans ce cache. Le lancement subs\u00e9quent de l\u2019utilitaire \u00ab su \u00bb conduira \u00e0 charger en m\u00e9moire non le fichier ex\u00e9cutable original depuis le stockage, mais une version modifi\u00e9e provenant du cache m\u00e9moire. <\/p>\n
La divulgation d'informations sur les vuln\u00e9rabilit\u00e9s et la publication coordonn\u00e9e des mises \u00e0 jour corrigeant les probl\u00e8mes \u00e9taient pr\u00e9vues pour le 12 mai, mais en raison d'une fuite d'informations, les d\u00e9tails sur la vuln\u00e9rabilit\u00e9 ont d\u00fb \u00eatre publi\u00e9s avant la publication des correctifs. Fin avril, des correctifs pour rxrpc, ipsec et xfrm ont \u00e9t\u00e9 publi\u00e9s sur la liste de diffusion publique netdev, sans mention qu'ils \u00e9taient li\u00e9s \u00e0 la correction d'une vuln\u00e9rabilit\u00e9. Le 5 mai, le mainteneur du sous-syst\u00e8me IPsec a int\u00e9gr\u00e9 dans le d\u00e9p\u00f4t git netdev un changement avec un correctif propos\u00e9 dans le module xfrm-esp, dont la description r\u00e9p\u00e9tait en grande partie celle du probl\u00e8me ayant conduit \u00e0 la vuln\u00e9rabilit\u00e9 Copy Fail dans le module algif_aead. L'un des chercheurs en s\u00e9curit\u00e9 s'est int\u00e9ress\u00e9 \u00e0 ce correctif, a r\u00e9ussi \u00e0 cr\u00e9er un exploit fonctionnel et l'a publi\u00e9, sans avoir connaissance de l'embargo sur les d\u00e9tails du probl\u00e8me avant le 12 mai. <\/p>\n