Un bug dans Cryptsetup permet sous Linux de contourner la demande de mot de passe quand l’unité de stockage a été chiffrée. La faille qui en résulte peut être exploitée aussi bien localement qu’à distance. Explications.

C’est un chercheur en sécurité espagnol, Hector Marco, qui a soulevé le lièvre. Celui-ci réside dans l’utilitaire Cryptsetup, très utilisé pour le chiffrement des disques durs et autres SSD, que ce soit sur des machines personnelles, des postes de travail ou des serveurs. Il est exploitable via LUKS (Linux Unified Key Setup), installé par défaut avec Debian et Ubuntu notamment. On le trouve donc sur de très nombreuses machines.

Votre machine est trop lente, réessayez

C’est en inspectant le processus de démarrage que Marco a repéré un souci. Lors de cette phase, un mot de passe est nécessaire pour continuer. Il sert à déverrouiller l’accès aux données chiffrées, la séquence de boot ne l’étant pas. Malheureusement, la gestion de ce mot de passe comporte une faille. Comme expliqué par le chercheur, Cryptsetup s’appuie sur plusieurs scripts de vérification de l’identifiant, et quand le nombre de tentatives dépasse trois (maximum par défaut), la séquence de démarrage relance la procédure d’authentification.

Cette erreur est engendrée par une mauvaise interprétation des actions par les scripts. Cryptsetup considère alors que la machine est lente et qu’elle a besoin d’un peu plus de temps pour laisser l’utilisateur taper son mot de passe en toute tranquillité. En tout, elle peut être relancée jusqu’à 30 fois sur un système de type x86, pour un total donc de 93 tentatives. Le chiffre grimpe même jusqu’à 150 fois sur une machine PowerPC, avec 453 tentatives en tout.

Au bout de la route, un shell et des droits root

Le souci ne serait pas si grave si Cryptsetup n’avait pas été, selon les propres mots du chercheur, « pensé par des développeurs, pour des développeurs », comme un grand nombre de produits du monde Linux. En cas de problème, le développeur trouvera des moyens de s’en sortir, via des outils spécifiques qui n’attendent que lui. Dans le cas de l’utilitaire de chiffrement, il s’agit d'une invite de commande (shell).

Cryptsetup, quand il arrive au bout des tentatives d’authentification, lance un shell Initrd avec des droits root. En d’autres termes, un utilisateur malveillant qui souhaiterait simplement y accéder n’a qu’à contourner les demandes. Pour ce faire, il n’a qu’à laisser la touchée Entrée enfoncée pendant environ 70 secondes. Les tentatives de mots de passe défilent alors et laissent place au shell et à ses commandes.

Localement ou à distance

Toujours selon le chercheur, le pirate qui aurait accès à la machine pourrait réaliser de nombreuses actions. Par exemple, placer un exécutable qui serait alors présent au démarrage pour provoquer plus tard une escalade des privilèges. Il serait même possible de remplacer le kernel.

Les données des partitions, même si elles sont chiffrées, pourraient être copiées vers un périphérique externe en vue d’une attaque par force brute plus tard. Ou plus simplement, le pirate pourrait effacer les données. Il reste que, si l'identification via Cryptsetup peut être contournée, le chiffrement des fichiers en eux-mêmes n'est pas directement affecté.

Cette attaque requiert un accès physique à la machine, mais Hector Marco précise qu’elle peut être exploitée à distance, notamment sur les serveurs cloud, où Linux est monnaie courante. Il ne donne par contre pas d’indication sur ce deuxième cas de figure.

Une faille simple à corriger, des patchs arrivent 

Pour le chercheur, il est évident que ce shell ne devrait pas être présent, ou en tout cas pas dans la configuration par défaut, dans des systèmes conçus pour être exploités tels quels. Les besoins des développeurs ne devraient pas être prioritaires, et rien n’empêcherait une simple option d’être activée plus tard. Sans le shell, le problème de sécurité des mots de passe reste, mais devient nettement moins important, ne laissant finalement « que » 93 ou 452 tentatives selon les cas.

La faille de sécurité, estampillée CVE-2016-4484, est selon lui très facile à corriger. Il a proposé un correctif qui supprime le shell et provoque un blocage du processus de boot tant que le bon de mot de passe n’a pas été entré. On ne sait pas exactement si ce patch a été repris tel quel, mais un correctif a été implémenté dans la version 2:1.7.3 - 2 de Cryptsetup, même s’il ne s’agit pas encore de la branche stable. Comme l’indique BleepingComputer, le correctif a été diffusé le 7 novembre dans les mises à jour des distributions Debian, mais Canonical a repoussé sa diffusion, pour une raison encore inconnue.

Il faudra donc patienter la diffusion des correctifs. Entre temps, Hector Marco a également découvert que tous les systèmes utilisant Dracut au lieu de initramfs sont également vulnérables, notamment les distributions Fedora.

Même si la faille est très simple à colmater, la simplicité avec laquelle une protection peut être contournée reste surprenante. Elle rappelle largement celle détectée dans Grub2 en fin d’année dernière : on pouvait court-circuiter la demande de mot de passe en pressant 28 fois la touche Retour Arrière (backspace) à cause d’un bug arithmétique.