En informatique, une confiance aveugle est souvent accordée au “ code historique”, celui qui innerve des millions de serveurs depuis des années sans jamais faire parler de lui. On aimait penser que le noyau Linux, fort de sa nature open source et d’audits permanents, était une forteresse imprenable.
La découverte de la vulnérabilité Copy Fail vient prouver le contraire. Nichée au cœur même des fondations cryptographiques de Linux, cette faille de logique a survécu à une décennie d’analyses humaines avant d’être mise à nu en quelques minutes par une intelligence artificielle.
Aujourd’hui, Jean-Pierre GARNIER, notre manager SOC, décrypte les rouages techniques de cette menace, ses impacts pour votre entreprise et les stratégies pour vous en prémunir.
Quelle est l’origine de la vulnérabilité “Copy Fail” ?
Pour comprendre Copy Fail, il faut remonter à 2017. À cette époque, les développeurs du noyau Linux introduisent une optimisation dans l’API, dans l’interface de programmation liée à la cryptographie sur le système.
L’idée était noble : éviter de copier inutilement des données en mémoire, de gagner du temps et en performance.
Malheureusement, c’est précisément cette “tentative de raccourci” qui a créé une faille logique. On a préféré la vitesse au détriment d’une vérification stricte des accès.
Note : cette vulnérabilité a été mise au jour par Taeyang Lee (Theori) grâce à Xint Code, un outil d’audit assisté par IA. Les versions du noyau Linux impactées s’étendent de la 4.14 à la 6.19.12 |
Comment fonctionne cette attaque techniquement ?
Techniquement, c’est une attaque qu‘on appelle de corruption de page de cache. Concrètement, si on utilise une fonction système toute faite pour lier un fichier à une opération de calcul, à cause de cette faille, le système se retrouve à s’emmêler les pinceaux et à laisser écrire, quelques octets, quelques portions de la donnée directement là où le code du programme est stocké en mémoire vive.
En gros, on peut modifier un programme sécurisé pendant qu’il tourne sans même toucher aux fichiers sur le disque.
Décryptage technique
L’exploitation de cette vulnérabilité nécessite l’utilisation répétée de l’appel système splice(). Cette faille, découlant d’une optimisation (la fusion de mémoire), permet d’écrire quatre octets consécutifs sur un fichier pour lequel un utilisateur local ne possède pas de droits d’écriture (un fichier qui était censé être protégé en lecture seule).
En réitérant cette commande, l’attaquant remplace une partie des instructions légitimes du programme /usr/bin/su par son propre code malveillant directement dans la RAM. Lorsque ce programme s’exécute ensuite, son code malveillant tourne avec les droits root.
Les conteneurs sont particulièrement vulnérables à cause de cette faille (Copy Fail), car le cache est partagé entre l’hôte et les conteneurs. Si un attaquant réussit à exploiter une simple vulnérabilité web dans un conteneur isolé, il peut utiliser ce cache mémoire partagé pour s’échapper (évasion ou breakout). Une telle compromission permet alors non seulement une évasion, mais également une escalade de privilèges sur l’ensemble du nœud, compromettant l’intégralité du serveur et de tous les autres conteneurs qui y résident, au-delà de la seule application initialement visée.
Voici les détails étape par étape de l’exploitation de CopyFail :
- Accès initial et prérequis :
L’attaquant doit d’abord obtenir un accès local avec des privilèges standards (non privilégiés) sur une machine exécutant un noyau Linux vulnérable. - Exécution du script d’exploitation :
L’attaquant lance un très court script Python (environ 732 octets) qui ne nécessite aucune compilation, aucun accès réseau, ni aucune dépendance tierce complexe. Deux commandes suffisent : wget pour récupérer l’exploit, python3 pour l’exécuter. Trois secondes plus tard, l’attaquant a un shell super admin. (L’élévation de privilèges est effective en environ 2,84 secondes)
Plus d’explications sur le script :
- Le script ouvre un socket AF_ALG, qui est l’interface en espace utilisateur pour l’API cryptographique du noyau, en ciblant spécifiquement le module authences.
- En combinant ce socket AF_ALG avec l’appel système splice(), l’attaquant déclenche une faille logique issue d’une optimisation introduite dans le code en 2017. Le noyau tente à tort de réutiliser un buffer source en mémoire comme destination pour l’opération cryptographique.
- Lorsque cette optimisation échoue, une erreur de manipulation permet au script d’écrire 4 octets contrôlés par l’attaquant au-delà de la zone autorisée, directement dans le page cache du noyau. L’attaquant utilise ces 4 octets pour altérer la représentation en mémoire d’un binaire privilégié doté du bit setuid, tel que /usr/bin/su. Aucun fichier n’est modifié sur le disque dur, ce qui permet à l’attaque de contourner les systèmes de détection, de modification de fichiers une fois la mémoire vidée ou le système redémarré.
L’attaquant exécute finalement le binaire /usr/bin/su ciblé. Puisque le noyau lit la version altérée qui se trouve dans le cache de pages au lieu du fichier sain sur le disque, l’exécution s’effectue avec les droits de superadministrateur, octroyant un shell root immédiat (UID 0) à l’attaquant.
Quels sont les systèmes concernés et quels sont les risques spécifiques pour les utilisateurs ?
Le périmètre est immense, et c’est d’ailleurs pour cela qu’on aborde ce sujet aujourd’hui. Quasiment toutes les distributions Linux majeures comme Ubuntu, Debian ou RedHat, sont touchées. Le risque numéro un reste l’élévation privilège. Un utilisateur lambda, ou même un logiciel malveillant avec très peu de droits, peut dans certains cas exploiter cette vulnérabilité prendre le contrôle de l’ensemble du système. Prendre un accès root sur ce système en un clin d’œil.
Pour le cloud, c’est quelque chose qui, sous un certain angle, peut être terrifiant. Cela permet potentiellement de s’échapper d’un conteneur, notamment d’un conteneur Docker, pour aller corrompre le serveur qui l’héberge et, à terme, éventuellement se propager sur l’ensemble d’un écosystème cloud.
Le risque majeur reste l‘élévation de privilèges en tant qu’administrateur, permettant ainsi à l’attaquant de pouvoir se matérialiser à l’échelle d’un système en entier. L’objectif peut être le vol de données ou du sabotage, quelle qu’en soit la finalité : prédation financière, déstabilisation ou encore vol de propriété intellectuelle.
Comment expliquer qu’une faille introduite en 2017 ait pu échapper aux audits humains pendant 9 ans, pour être identifiée par l’IA Xint Code en seulement une heure ?
C’est un peu la grande leçon de cette affaire. Copy fail, ce n’est pas vraiment une erreur de frappe, c’est un défaut de logique entre deux composants qui, séparément, fonctionnent très bien. Un auditeur humain a une attention limitée, il a des angles morts et des biais cognitifs ; s’il audite chacun de ces composants séparément, il va se retrouver à considérer que l’ensemble du code est cohérent et exempt de toute vulnérabilité.
L’IA, elle, est parvenue à simuler des millions d’interactions possibles en seulement 1h. Elle ne s’est pas contentée de lire le code, elle a compris comment il pouvait être détourné. Là où l’humain n’y a vu qu’une simple optimisation classique.
Pourquoi cette vulnérabilité est-elle particulièrement redoutable ?
Elle est redoutable parce qu’elle est universelle, mais surtout parce qu’elle est propre. Les principales vulnérabilités majeures sur le canal Linux, on pense notamment à Dirty COW, bien connu au début des années 2000, sont des failles qui rendent complètement instables les systèmes et peuvent faire planter un serveur.
Copy Fail, en revanche, est chirurgicale : elle réussit à chaque fois. Elle laisse très peu de traces sur le système d’exploitation, dans les journaux d’événements, et le script en tant que tel ne rend pas instable la machine. Cela permet à l’attaquant d’opérer et d’atteindre son objectif sans perturber le fonctionnement de la cible qu’il vient de compromettre. Au final, c’est l’arme parfaite pour une intrusion silencieuse.
Comment corriger le problème ou s’en prémunir ?
Il faut mettre à jour le noyau Linux. Les correctifs sont sortis pour la plupart des distributions, il n’y a pas de mesure de contournement à appliquer. Il faut patcher au plus vite. Si l’on ne peut pas redémarrer le serveur tout de suite parce que d(ce qui sera nécessaire dans certains cas ), on peut à minima désactiver le module incriminé pour pouvoir utiliser des outils de chiffrage pour bloquer les systèmes suspects et ainsi mitiger cette vulnérabilité en attendant un redémarrage. Il ne faut donc pas tarder, surtout en entreprise, à mettre à jour son système.
Le conseil de notre expert : si redémarrer la machine est impossible, il existe une solution de contournement : Il s’agit de désactiver le module qui permet l’attaque : algif_aead. echo « install algif_aead /bin/false » > /etc/modprobe.d/disable-algif.conf rmmod algif_aead 2>/dev/null || true |
Attention, il peut y avoir des effets de bord suite à cette désactivation, cela désactive les sockets AEAD, donc les IPSec peuvent être affectés.
Quelles sont les implications pour l’avenir de la cybersécurité face à l’IA ?
L‘IA et la cyber, c’est un vaste domaine. On voit aujourd’hui que l’IA est prépondérante à la fois en offensif comme en défensif. Nous entrons dans une ère de sécurité marquée par une part d’asymétrique, où l’IA va devenir le meilleur ami des attaquants en leur permettant de découvrir massivement des nouvelles vulnérabilités, notamment des zero-days.
Mais c’est aussi une vraie chance pour nous en tant que défenseur, pour avoir de meilleures pratiques de développement, de meilleures pratiques de patch management. Cela va nous permettre de prendre l’ascendant sur toutes ces techniques. Des millions de lignes de code héritées du passé vont ainsi pouvoir être auditées par ce « second couteau », offrant une nouvelle façon d’identifier de potentielles vulnérabilités. Les tests de pénétration classiques, les revues de code classiques vont être complétées pour vraiment assurer une défense en profondeur sur les systèmes.
Comment les entreprises peuvent-elles être accompagnées face à ces menaces complexes ?
Les entreprises ne peuvent pas rester seules. Pour la plupart, elles n’ont ni les ressources, ni les moyens nécessaires. Elles doivent passer d’une sécurité dite “périphérique” à une sécurité de résilience. Cela signifie que, dans la quasi-totalité des cas, ces sociétés vont devoir être accompagnées pour mettre en place une analyse continue. Celle-ci croisera à la fois l’humain et l’IA qui reposera sur des processus robustes et qui leur permettra de tenir sur la durée tout en limitant les risques d’un incident de sécurité.
Dans cette perspective, Synetis. En tant que pure players de la cybersécurité couvre l’ensemble des pans de l’identité numérique à la GRC, à l’audit, à la cyberdéfense, avec le SOC et le CERT. Aujourd’hui, c’est une entreprise capable d’accompagner l’ensemble des bénéficiaires dans une approche complètement transverse.
