Hector Marco de l’université d’Écosse de l’Ouest et Ismaël Ripoll de l’école polytechnique de Valence en Espagne, ont révélé l’existence d’une faille de sécurité dans Cryptsetup, qui permet de récupérer un shell de secours en root sur certains systèmes.
Cryptsetup pour ceux qui ne connaitraient pas, est un outil utilisé pour chiffrer des systèmes de fichiers sous Linux, qui implémente le standard LUKS (Linux Unified Key Setup). C’est ce qui est utilisé par exemple, par défaut sous Debian et Ubuntu lorsque vous activez le chiffrement de votre disque dur.
A priori, la faille se situerait dans un script livré dans le package Debian cryptsetup <= 2:1.7.2-3. Si vous êtes sous Fedora, vous êtes aussi concerné, car Cryptsetup est utilisé par Dracut, un outil qui permet de générer des systèmes de fichier en RAM (initramfs).
En passant, je ne sais pas si vous avez vu mais l’hébergeur Hostinger propose des offres super intéressantes en matière d’hébergement web. C’est pas trop cher pour démarrer et s’auto-héberger. (Lien affilié)
La faille CVE-2016-4484 est facile à exploiter. Il suffit d’avoir un accès à une console sur la machine, et lorsque le mot de passe LUKS est demandé, il suffit d’appuyer sur la touche « Entrée » un grand nombre de fois jusqu’à ce qu’un shell apparaisse. On ne peut pas faire plus simple. J’avoue je n’ai pas encore testé, mais les chercheurs à l’origine de la découverte disent que ça ne prend pas plus de 70 secondes.
Voici une démonstration :
En effet, une fois que le nombre maximum de mots de passe erronés est atteint, la séquence de boot se poursuit normalement et un autre script présent dans Cryptsetup prend le relai et balance un shell BusyBox ou initramfs.
Le risque d’exploitation est élevé dans les lieux publics où il y a des bornes Linux (Distributeurs de billets, bornes dans les aéroports…etc.) car il suffit de rebooter la machine en douce (et y brancher un clavier) sans parler de certaines instances Linux accessibles en ligne comme celles proposés par le Cloud Ubuntu, qui d’après ces mêmes chercheurs pourraient être exploitées à distance sans aucun accès physique. Vous trouverez plus de détails sur cette faille ici.
Bref, autant dire que ça ne sent pas très bon. Pour le moment, seul Debian a patché le truc, sans réagir publiquement, et les chercheurs ne sont pas d’accord avec la façon dont ce patch a été implémenté. D’après eux, le problème est plus général que ça, et viendrait du faire que la séquence de boot GNU/Linux est trop permissive avec les erreurs.
Et si vous ne voulez pas attendre, les chercheurs proposent le patch suivant à appliquer sur le script « scripts/local-top/cryptroot » :
