Fermer le menu
 

High Sierra révèle le mot de passe des volumes APFS chiffrés à la place de l'indice [màj]

Stéphane Moussie | | 09:18 |  121

Mise à jour — Apple a livré une version "supplemental" de macOS 10.13 qui corrige le bug.

Sur macOS High Sierra, un bug embêtant affecte les volumes APFS chiffrés. Un développeur a remarqué que le système révélait le mot de passe de ces volumes à la place de son indice.

Nous avons reproduit ce bug sur la bêta de macOS 10.13.1, qui ne corrige donc pas le problème. Dans l’Utilitaire de disque, il suffit de créer un volume APFS chiffré, entrer un mot de passe (« toto » dans notre cas) et un indice (« notre mdp habituel »), puis une fois créé, éjecter le volume et le monter. L’indice affiché par la boîte de dialogue n’est pas l’indice que nous avions saisi, mais le mot de passe (qui fonctionne bien).

« toto » est notre mot de passe, pas notre indice…
Catégories: 

Les derniers dossiers

Ailleurs sur le Web


121 Commentaires Signaler un abus dans les commentaires

avatar byte_order 05/10/2017 - 10:19

Comme le mot de passe est affiché (par erreur, certes) cela signifie quand même qu'il n'est pas sauvegardé après hashing... et même qu'il n'est pas passé par du hashing asap, puisque sa valeur en clair semble avoir pu être utilisé soit à l'écriture - par erreur - comme indice soit à la relecture dudit indice,
ce qui constitue une faille également.

avatar BeePotato 05/10/2017 - 10:43

@ byte_order : « Comme le mot de passe est affiché (par erreur, certes) cela signifie quand même qu'il n'est pas sauvegardé après hashing... et même qu'il n'est pas passé par du hashing asap, puisque sa valeur en clair semble avoir pu être utilisé soit à l'écriture - par erreur - comme indice soit à la relecture dudit indice, ce qui constitue une faille également. »

Je ne vois pas bien où tu veux en venir.
Le fait que le mot de passe se retrouve enregistré par erreur à la place de l’indice, c’est évidemment une faille, causée par une erreur bête.
Mais c’est tout, ça ne révèle aucune autre faille dans le processus normal de création des images chiffrées.

avatar Hasgarn 05/10/2017 - 11:37 via iGeneration pour iOS (edité)

@BeePotato

Je ne suis pas trop d'accord avec Byte puisqu'on sait que le disque a été démonté avant d'être remonté. Il y a eu sauvegarde du mot de passe sur le volume crypté.
Ce qui veut dire que le mot de passe est certainement stocké non hashé (point que je soulève). Et que le fait de le requêter devrait plutôt nous renvoyer le mot de passe hashé plutôt que le mot de passe en clair.
Bref, c'est vraiment mauvais.



avatar r e m y 05/10/2017 - 11:48 via iGeneration pour iOS

@Hasgarn

Non je pense que le mot de passe est bien stocké hashé... mais l'indice lui est stocké en clair.
Or lors de l'enregistrement c'est aussi le mot de passe qui a été pris comme indice et donc enregistré une fois hashé comme mot de passe, et une fois en clair comme indice.
(Le véritable indice, lui, a ete perdu corps et biens)

avatar Hasgarn 05/10/2017 - 14:06

C'est une possibilité parmi toutes celles dont on parle.

avatar byte_order 05/10/2017 - 20:58

Et ce que je dis c'est que quand on fait les choses bien en matière de sécurité, la chaine contenant le mot de passe en clair doit immédiatement être passé au hashing afin, justement, de virer le plus vite possible toute trace de la valeur saisie en mémoire... et ailleurs, en cas de bug comme ici.

Si cela avait été le cas, c'est le hashing de "toto" qu'on retrouverait comme indice, pas "toto".

avatar BeePotato 06/10/2017 - 09:56

@ byte_order : « Et ce que je dis c'est que quand on fait les choses bien en matière de sécurité, la chaine contenant le mot de passe en clair doit immédiatement être passé au hashing afin, justement, de virer le plus vite possible toute trace de la valeur saisie en mémoire... et ailleurs, en cas de bug comme ici. »

Sauf que dans ce genre de chose, « immédiatement », ça n’existe pas. Il y a forcément toujours un moment où le mot de passe est présent en clair dans la mémoire, pendant que l’utilisateur le saisit.
C’est à ce moment-là qu’il a été copié par erreur dans la variable censée recevoir l’indice.

Il n’y a rien de choquant à ce que cette erreur soit possible à ce moment-là, et non, ça ne remet pas en cause le fond du fonctionnement de la création d’un volume chiffré.

avatar BeePotato 05/10/2017 - 11:58

@ Hasgarn : « Ce qui veut dire que le mot de passe est certainement stocké non hashé (point que je soulève). Et que le fait de le requêter devrait plutôt nous renvoyer le mot de passe hashé plutôt que le mot de passe en clair.
Bref, c'est vraiment mauvais. »

Mais non ! Le mot de passe n’est normalement pas stocké du tout, vu qu’il n’y en a pas besoin (quand on le demande à l’utilisateur au montage de l’image disque, ce n’est pas pour de l’authentification, mais pour du déchiffrage).

Là, sa version en clair se retrouve stockée à la place de l’indice, mais c’est juste une erreur faite au moment de la création de l’image disque (moment où il n’est pas étonnant du tout que le processus demandant la création de l’image et fournissant les informations nécessaires dispose du mot de passe en clair, puisque l’utilisateur vient de le lui donner).

En gros, il n’y a pas de requête du mot de passe au moment du montage (correspondant à la capture d’écran). Il s’agit bien d’une requête de l’indice, mais qui renvoie une information erronée parce que c’est une information erronée qui a été stockée dans l’image disque lors de sa création.

avatar Hasgarn 05/10/2017 - 14:12 (edité)

Explique moi comment tu fais pour t'assurer que le mot de passe est bon si tu ne le stockes pas ?

Elle est d'autant plus bizarre, ton explication, que tu parles de requête de mdp donc de recherche en BDD du mot de passe stocké.

J'ai du mal à te suivre ;)

Et puis faut me dire en quoi mon analyse est erroné : il peut très bien s'agir d'une interversion de données à la création de la vue. Et à la limite, c'est un moindre mal par rapport à ce que tu décris.

avatar BeePotato 05/10/2017 - 14:23

@ Hasgarn : « Explique moi comment tu fais pour t'assurer que le mot de passe est bon si tu ne le stockes pas ? »

Facile : il permet de déchiffrer les données, alors qu’aucun autre ne le permet. :-)
On parle de chiffrement/déchiffrement, là, et pas d’authentification. Il n’y a aucun besoin de stocker le mot de passe avec les données — et ce serait une hérésie de le faire.

« Elle est d'autant plus bizarre, ton explication, que tu parles de requête de mdp »

Non. Relis correctement, y compris ce que tu as écrit : j’ai parlé de requête de mot de passe pour dire qu’il n’y en a pas, en réponse au fait que toi, tu parlais de faire une telle requête.

« Et puis faut me dire en quoi mon analyse est erroné »

Je l’ai déjà fait, et je t’invite à relire l’explication.

« il peut très bien s'agir d'une interversion de données à la création de la vue. »

Non, puisque le mot de passe ne peut pas être connu à ce stade du processus. Le seul truc qu’on puisse récupérer au moment du montage d’une telle image disque, c’est l’indice de mot de passe. Il ne peut donc pas y avoir d’inversion de données puisqu’il n’y en a qu’une seule, de donnée.

Le seul problème ici est qu’un incompétent s’est retrouvé à écrire le mot de passe en clair à l’endroit où il aurait dû écrire l’indice, ce qui donne du coup l’accès au mot de passe à un moment où il ne devrait plus exister nulle part sauf dans la tête de l’utilisateur.

« Et à la limite, c'est un moindre mal par rapport à ce que tu décris. »

Absolument pas, puisque ce que tu décris impliquerait qu’il y aurait, même sans ce bug, une façon de récupérer le mot de passe à partir de l’image disque chiffrée. Ça, ce serait « vraiment mauvais » (pour reprendre tes termes).

avatar Hasgarn 06/10/2017 - 12:58 via iGeneration pour iOS

@BeePotato

Et les autres.
Merci pour vos explications.
Si avec ça, j'ai pas compris...

avatar C1rc3@0rc 05/10/2017 - 21:10

@Hasgarn

«Explique moi comment tu fais pour t'assurer que le mot de passe est bon si tu ne le stockes pas ?»

dans cette phrase tu démontres que ignores absolument tout du domaine dont tu veux parler en affirmant crânement une hypothèse fortement improbable.

C'est le b.a.ba de l'informatique, on ne stocke jamais un mot de passe avec les données chiffrées (c'est un non sens absolu), et il n'y a aucun besoin d'avoir le mot de passe en clair pour déchiffrer...

avatar byte_order 05/10/2017 - 21:04

> Explique moi comment tu fais pour t'assurer
> que le mot de passe est bon si tu ne le stockes pas ?

On "hash" le mot de passe proposé et on le compare avec le "hash" enregistré du mot de passe valide (notez que ce qui enregistré c'est bien le hash du mot de passe valide, pas le mot de passe valide lui même).

Le hashing étant une transformation non réversible, il est très difficile de retrouver la valeur du mot de passe, mais très facile de le comparer avec le même hashing fait sur une chaine quelconque.

avatar bunam 05/10/2017 - 13:06

En fait le mot de passe est dérivé avec du PBKDF2-HMAC-SHA-1 pour obtenir la clé de chiffrement/déchiffrement.
On fait passer le mot de passe dans la routine, le retour de la routine est remis dans celle-ci 250 000 fois apparemment pour les DMG
https://www.whitehatsec.com/blog/cracking-aes-256-dmgs-and-epic-self-pwn...

C'est très lent et c'est fait exprès pour éviter qu'un "couillon" qui voudrait accéder à un DMG, tente tous les mots de passe trop rapidement.

PBKDF2 est pour le moment notre ami...

avatar Hasgarn 05/10/2017 - 11:38 via iGeneration pour iOS

@BeePotato

Bien sûr que le mot de passe semble fonctionner, mais il y a inversion des 2 chaînes lors de la création de la vue.

avatar BeePotato 05/10/2017 - 14:10

@ Hasgarn : « Bien sûr que le mot de passe semble fonctionner, mais il y a inversion des 2 chaînes lors de la création de la vue. »

Non.
Selon toute vraisemblance, le bug n’est pas à ce moment-là, mais au moment de la création.
Et il ne s’agit alors pas d’une inversion de chaînes, mais d’une utilisation de la même chaîne deux fois (sinon, il faudrait utiliser l’indice à la place du mot de passe pour déverrouiller l’image).

avatar Pobla Picossa 05/10/2017 - 09:46 via iGeneration pour iOS

J’imagine la réaction de St Jobs s’il était encore là...

avatar BeePotato 05/10/2017 - 09:57

Ça, c’est de l’indice efficace ! :-)

Les boulets…

avatar monobloclimber 05/10/2017 - 09:59

Normalement le mot de passe est sensé être crypté et indécryptable. Du coup si ce bug l'affiche ici, c'est qu'il ne l'est pas...

avatar bunam 05/10/2017 - 10:16

Non s'il a été interverti avec l'indice du mot de passe au moment de l'enregistrement du .dmg, ce qui est une ENORME erreur de la part du développeur.

avatar françois bayrou 05/10/2017 - 13:40

"être crypté et indécryptable"

OUhlala ca pique les yeux
http://blog.securite.free.fr/index.php/difference-chiffrer-crypter-decry...

avatar Sir Rendal 05/10/2017 - 09:59 via iGeneration pour iOS

Franchement Apple se barre en sucette.
Bug a gogo en ce moment.

avatar dtb06 05/10/2017 - 10:00

Du LOL en barre avec Apple !

avatar chepiok 05/10/2017 - 10:00 (edité)

Plus que l'inversion de l'information affichée, ce qui est étonnant c'est que le système garde le mot de passe sous une forme lisible. La base en sécurité est de ne jamais stocker un mot de passe en clair. Je suis très surpris !

avatar BeePotato 05/10/2017 - 14:11 (edité)

@ chepiok : « Plus que l'inversion de l'information affichée, ce qui est étonnant c'est que le système garde le mot de passe sous une forme lisible. La base en sécurité est de ne jamais stocker un mot de passe en clair. Je suis très surpris ! »

L’explication est simple : le mot de passe n’est jamais stocké, ni en clair, ni sous forme chiffrée, car il n’y en a tout simplement pas besoin — mais l’indice de mot de passe, lui, est évidemment stocké en clair, sinon il serait totalement inutile. Du coup, quand un développeur se trompe et fait enregistrer à cet endroit la chaîne de caractères correspondant au mot de passe et non celle de l’indice, ça file forcément un mot de passe en clair. Mais ça n’indique rien de négatif au sujet du comportement normal de ce système. Là, il s’agit d’une bête erreur en amont, plutôt que d’une erreur de conception du système de chiffrement.

Pages