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

Stéphane Moussie |

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…
avatar 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.

avatar BeePotato | 

@ 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 | 

@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 | 

@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 | 

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

avatar 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.

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

avatar BeePotato | 

@ 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 | 

@ 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 | 

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 | 

@ 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 | 

@BeePotato

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

avatar C1rc3@0rc | 

@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 | 

> 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 | 

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-pwnage/

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 | 

@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 | 

@ 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 | 

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

avatar BeePotato | 

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

Les boulets…

avatar monobloclimber | 

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 | 

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 | 

"être crypté et indécryptable"

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

avatar Sir Rendal (non vérifié) | 

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

avatar dtb06 | 

Du LOL en barre avec Apple !

avatar 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 !

avatar BeePotato | 

@ 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.

avatar r e m y | 

@chepiok

Probablement que le bug existe au niveau de l'enregistrement... le mot de passe peut être stocké de façon cryptée, mais l'indice, lui, être stocké en clair (pour pouvoir ensuite l'afficher).
Si c'est la variable "mot de passe" qui a été prise comme variable "indice" au moment de son enregistrement, alors il a été stocké en clair parce que confondu avec l'indice (je ne sais pas si je suis très clair pour le coup...)

avatar minipapy | 

@r e m y

Le mot de passe, dans ce type de cas de figure, n’a même pas à être stocké puisqu’il s’agit d’une bête clé de déchiffrement et non pas d’un élément d’authentification.

Nul besoin d’associer le mot de passe à une entité et donc nul besoin de le conserver. Entrer le mot de passe enclenche simplement le processus de déchiffrement avec comme clé ledit mot de passe. Si en résulte des données compréhensibles, la clé est bonne.

avatar r e m y | 

@minipapy

Pourtant si on ne saisit pas le bon mot de passe, on en est immédiatement averti...

avatar alan1bangkok | 

Un par jour
Une belle constance
Bizarrement les fanboys sans queue ni tête sont absents de ce topic......

avatar sinbad21 | 

Ça pour une faille de sécurité c’en est une belle. C’est énorme, et ça renforce l’impression que le nouveau système a été mis sur le marché un peu trop tôt.

avatar macam | 

@sinbad :
Comme pour tout projet, dès lors que l'on se donne une date butoire (pour Apple chaque fin de mois de septembre), on n'atteint rarement ses objectifs à la dite fixée. Avec un chantier tel que le remplacement de HFS+ par APFS on pouvait s'attendre à des erreurs en pagaille.

avatar radar | 

Étant donné que le mot de passe n'est pas censé être retrouvé, je pense qu'au moment de l'enregistrement, ils stockent le mot de passe à la place de l'indice.

avatar r e m y | 

Mais tout ça n'explique pas comment MON mot de passe apparaît comme indice d'un disque crypté par MacG! ?

avatar Stéphane Moussie | 
@r e m y : une backdoor dans iCloud, rien de plus facile.
avatar r e m y | 

@stephmouss

J'en étais sûr...
MacG est installé à Lyon, tout comme Interpol, ça ne peut pas être une coïncidence! ?

avatar codeX | 

Un peu l'inverse qui se passe lorsque c'est Samsung, Google et consorts qui sont pris en défaut. S'en branler le bout de chambre à air relève au mieux de l'ennui profond au pire d'un grave problème cognitif. Allez, on bouge sa petite queue et on retourne travailler.

avatar macam | 

@codex :
Déjà trois pages de forum à l'heure ou tu écris ton commentaire...

avatar byte_order | 

Mais arrettez de troller, c'est le portage de FaceID sur macOS, c'est tout. Le nom FacePalmID n'est pas encore définitif toutefois...

avatar jpetit2 (non vérifié) | 

Incroyable! A quoi servent les "Bétas"'? A rien manifestement. A moins que les testeurs bêtas le soient à peine moins que ces bêtas de développeurs. Depuis 25 ans que je suis Apple au jour le jour, je n'ai jamais vu autant de cagasses que cette année et chaque année apporte un peu plus de bogues.
Apple est à un tournant : arrêter la complexification des systèmes (sans réel bénéfice pour l'utilisateur) ou stopper cette complexification technicienne et privilégier à toute force l'amélioration fonctionnelle (avec un réel bénéfice pour l'utilisateur).
Tim si tu me lis…

avatar macam | 

@jpetit :
Tu oublies les bêtas utilisateurs qui installent la golden master / version finale, qui sont les derniers testeurs de la chaîne.

avatar lepoulpebaleine | 

Fatche de con !

avatar DDivo | 

Il y a un sérieux problème de finition cette année, aussi bien sur iOS que HS :
- bugs et ralentissements (pas pour moi mais certains s'en plaignent et je ne les envie pas)
- incohérence de l'interface :
- iOS : emplacement des boutons clavier qui change selon l'orientation, ça devient un vrai casse tête et génère plein d'erreur de frappe
- iOS : le centre de contrôle qui ne désactive plus le WiFi ou BT : on ne comprend plus rien !
- iOS : autonomie bof
- macOS : iTunes 12.7 qui cache les sonneries
- macOS : qui révèle les mots de passe en clair
- macOS : Handoff qui marche quand ça veut
- macOS : WiFi qui ne respecte plus l'ordre de connexion qu'on préfère

et j'en passe ...

Simplicité, efficacité, Apple a oublié

avatar carabat | 

Ce n'est pas High Sierra, c'est High Vista. :p

avatar r e m y | 

@carabat

Non juste Aïe Sierra....

avatar mk3d | 

?? les stagiaires ont pris du grade chez Apple?

avatar Armaniac | 

Ou alors ils ont intégré les jardiniers dans les équipes de dev, je sais pas...

avatar Chris66 | 

Tim va nous expliquer que l'on a rien compris à cette nouvelle amazing fonction de sécurité de High Sierra.
Désormais, on vous file le mot de passe, et vous devez taper l'indice dans la zone de saisie... :-)

avatar Moonwalker | 

Le F.B.I. va encore piquer une crise.

avatar sinbad21 | 

C'est le principe de la lettre volée d'Edgar Poe. Pour mieux la dissimuler, on la place en évidence sur la cheminée.

avatar jmquidet | 

Désolé, je viens de tester et je ne constate pas ce bug…
iMac (21,5 pouces, fin 2012). Version bêta 10.13.1 (17B25c)

Pages

CONNEXION UTILISATEUR