Discussion :

[Stéphane le calme]

Linux : une faille dans l'outil de chiffrement de partitions Cryptsetup,
permet d'obtenir un accès root sur certaines machines

Durant l’édition 2016 de la conférence DeepSec, les chercheurs en sécurité Hector Marco (de l'université d'Écosse de l'Ouest) et Ismaël Ripoll (de l'école polytechnique de Valence en Espagne) ont donné plus de détails sur une faille critique, identifiée sous la référence CVE-2016-4484, qui touche l’utilitaire de chiffrement de disques durs Cryptsetup. Pour rappel, Cryptsetup est un logiciel utilisé pour chiffrer des systèmes de fichiers sous Linux, qui implémente le standard LUKS (Linux Unified Key Setup). Par défaut, il est proposé sur Debian, Ubuntu et Fedora 24 (depuis la version 2.6 du kernel) pour chiffrer les partitions.

Le problème se situe dans la gestion du mot de passe requis au sein de la séquence de démarrage du processus permettant de déverrouiller l’accès aux données chiffrées. Pour profiter de cette faille, il suffit donc d'avoir un accès à une console sur la machine. Le script de Cryptsetup a une erreur de conception qui permet à un utilisateur de réessayer le mot de passe plusieurs fois. Bien que ce ne soit pas suffisant pour faciliter une attaque par force brute, cela conduit à un problème plus important.

Une fois qu'un utilisateur a utilisé toutes les tentatives de mot de passe, l’outil va ouvrir un shell (Busybox dans Ubuntu) doté de privilèges root. Pour le faire apparaître, il suffit d’appuyer sur la touche “Entrée” pendant 70 secondes environ lorsque l'invite du mot de passe de déchiffrement du lecteur s'affiche pendant le démarrage du système.

Comme les chercheurs l’expliquent, la faille permet aux attaquants « d’obtenir un shell root initramfs [système de fichiers RAM initial] sur les systèmes affectés. La vulnérabilité est très fiable car elle ne dépend pas de systèmes ou de configurations spécifiques. Les attaquants peuvent copier, modifier ou détruire le disque dur ainsi que configurer le réseau pour exfiltrer les données. Cette vulnérabilité est particulièrement grave dans des environnements tels que les bibliothèques, les guichets automatiques, les machines d'aéroport, les laboratoires, etc., où le processus de démarrage est protégé (mot de passe en BIOS et GRUB) ».

Ils ont précisé que dans un environnement cloud il est également possible d’exploiter cette vulnérabilité à distance.

Pour les chercheurs, « la cause directe de cette vulnérabilité est la vérification incorrecte du nombre maximal de mots de passe, mais le bogue a été (probablement) introduit par l'ajout de nouvelles fonctionnalités (dans ce cas, des fonctions de sécurité). Il est bien connu que “la complexité est le pire ennemi de la sécurité”. Un système avec plus de fonctionnalités nécessite plus de code et a plus d'interactions entre les sous-systèmes, ce qui rend plus difficile de tester les systèmes et donc apporte plus de bogues ».

Quoiqu’il en soit, ils ont d’ores et déjà proposé un correctif qui bloque l’ouverture du shell au démarrage lorsque le nombre maximal de tentatives de mots de passe a été atteint.

Source : blog Hector Marco

[abriotde]

En sois ce n'est pas une faille du système de cryptage du disque maisjuste un moyen d'être root sur un PC ou on estpas cencé avoir accès. Mais si tous les disques sont crypté cela ne donne pas accès à grandchose....

[Blo0d4x3]

Mwouais, je trouve que c'est un peu bullshit et surtout pour faire du buzz, on peut très bien y avoir accès depuis grub ou un livecd.

[transgohan]

Une fois qu'un utilisateur a utilisé toutes les tentatives de mot de passe, l’outil va ouvrir un shell (Busybox dans Ubuntu) doté de privilèges root. Pour le faire apparaître, il suffit d’appuyer sur la touche “Entrée” pendant 70 secondes environ lorsque l'invite du mot de passe de déchiffrement du lecteur s'affiche pendant le démarrage du système.

Cela sort d'où ça ? C'est une fonctionnalité linux ou bien c'est le logiciel qui a une porte de debug qui n'est pas fermée ???
Car suivant la réponse c'est facilement corrigeable...

[gezedo]

Le titre de la news est quand même un peu trompeur : l'outil de chiffrement n'a aucune faille.

En revanche les scripts pour sa mise en oeuvre sont perfectibles. Ils constituent une faille de sécurité sur toutes les machines, mais cette faille n'a d'intérêt que sur les machines qui ont été préparées pour être protégées d'autres compromissions: Bios avec mot de passe, boîtier sécurisé / cadenassé, voire même port USB cimentés (voir PoisonTap). Pour les machines non sécurisées physiquement (la plupart ?) il est plus simple de démarrer avec un LiveCD, une clef usb, ou de manipuler les disques. Avoir accès physiquement à une machine est déjà une grande source de vulnérabilités.

Sauf erreur de ma part, les données chiffrées ne sont pas déchiffrées pendant "l'attaque". Mais il est vrai que le remplacement du kernel ou du ramdisk est possible et constitue un cheval de Troie pour accéder au PC lors du prochain démarrage par l'utilisateur légitime, ce dernier va ouvrir le disque chiffré, et à ce moment tout peut fuiter: qui va se rendre compte que le noyau de sa machine a été remplacé à son insu ?

[Squisqui]

En sois ce n'est pas une faille du système de cryptage du disque maisjuste un moyen d'être root sur un PC ou on estpas cencé avoir accès. Mais si tous les disques sont crypté cela ne donne pas accès à grandchose....

Être root sur un système dont on est pas censé avoir accès, si c'est pas une faille, qu'est-ce que c'est ?
Même si les données sont sur d'autres partitions, ça n'empêchera pas de faire son backdoor pour avoir accès à tout le reste lorsque la machine sera légitimement démarrée.
Et puis bon, de toute façon c'est corrigé.

[Blo0d4x3]

Être root sur un système dont on est pas censé avoir accès, si c'est pas une faille, qu'est-ce que c'est ?
Même si les données sont sur d'autres partitions, ça n'empêchera pas de faire son backdoor pour avoir accès à tout le reste lorsque la machine sera légitimement démarrée.
Et puis bon, de toute façon c'est corrigé.

Il ne s'agit pas d'une backdoor (ni d'une faille de sécurité), c'est normal d'avoir accès à l'initramfs, on le peut très bien depuis grub. On se retrouve avec un accès root sur /boot et les partitions non chiffrés ... super utile, et puis si le mec n'a pas chiffrer completement son OS et qu'on a accès à des logs ou autres, c'est plus la faute du mec qui a fait une installation foireuse que de crypsetup pour le coup.