High Sierra : explications sur le bug de mot de passe des volumes APFS chiffrés
Dévoiler le mot de passe à la place de l’indice, c’est ce que faisait l’Utilitaire de disque de High Sierra concernant les volumes APFS chiffrés avant qu’Apple ne sorte en catastrophe un correctif.
Quelle est la cause de ce bug énorme ? En l’absence d’explications précises de la part d’Apple, l’auteur du blog Cocoa Engineering s’est livré à un exercice détaillé de rétro-ingénierie.
Le développeur a commencé par comparer la version de l’Utilitaire de disque de High Sierra avec la nouvelle incluse dans la Supplemental Update. Résultat : aucune différence.
Il a alors poursuivi ses recherches dans les frameworks liés, dont StorageKit, le composant qui fait le lien entre APFS et l’Utilitaire de disque. En examinant son code, il a trouvé des différences entre les deux versions de StorageKit… et l’origine du bug.
Logiquement, il y a une variable pour le mot de passe et une autre pour l’indice. Or, c’était la même variable, celle du mot de passe, qui était utilisée comme valeur dans les deux cas, ce qui signifie que le mot de passe était considéré comme l’indice (et qu’il était stocké en clair).
Pas de faille dans APFS donc, il s’agissait d’une bête erreur de programmation — mais avec une lourde conséquence. « C’est un exemple typique de bugs où du code avec une structure commune est copié-collé sans que le développeur pense à effectuer toutes les modifications nécessaires », commente le chercheur.
Mais pourquoi le bug se produisait avec l’Utilitaire de disque mais pas avec les lignes de commandes ? Parce que ces deux méthodes n’utilisent pas exactement le même cheminement.
Rappelons que l’application de la mise à jour n’est pas suffisante à elle seule pour protéger les volumes APFS chiffrés créés avant son arrivée. Il faut supprimer et restaurer les volumes concernés, indique Apple.
N’empêche si la variable avait été celle de l’indice ça aurait vraiment été la merde
Le bug aurait sûrement été vu bien avant :)
Je ne comprends pas : est-ce que je dois reformater mon volume de démarrage et changer le mot de passe de ma session ?
Pour info :
- j’ai un MBPr13, son SSD avec 10.13 et mes données
- un DD externe (sauvegarde carbon copy cloner) en HFS+
- une Time Capsule, dans le mot de passe est le même que celui de ma session
- j’ai bien fait la mise à jour proposée par Apple
Non.
On parle ici des volumes chiffrés créés à l’aide de l’utilitaire de disque avant correction du bug.
@DDivo
Il ne faut faire quelque chose que si on comprend pourquoi c'est necessaire.
«est-ce que je dois reformater mon volume de démarrage et changer le mot de passe de ma session ?»
Le probleme dont on parle concerne High Sierra, la toute derniere version de MacOS (qui ne devrait pas etre installée a moins qu'on en ait vraiment la necessité).
Donc deja faut etre sous High Sierra: MacOS 10.13
Ensuite il faut verifier que le bug est present: quand on "ouvre" un disque chiffré (protege par un mot de passe) l'indice qui apparait apres quelques mot de passe erronés, c'est... le mot de passe!!!
Donc faut commencer par ouvrir le disque en tapant volontairement des mauvais mot de passe jusqu'a avoir l'aide qui affiche normalement l'indice qu'on avait inscrit lors du chiffrement du disque... et la si au lieu d'afficher l'indice c'est le mot de passe qui apparait, alors oui il faut:
sauvegarder les données
- mettre a jours MacOS
- effacer le disque
- chiffrer le disque
- reinstaller les données sur le disque.
Apres plusieurs remaques:
« un DD externe (sauvegarde carbon copy cloner) en HFS+»
C'est bien, meme tres bien. Faut juste avoir conscience qu'avec MacOS 10.13 il ne pourra pas servir de disque de demarage pour le Macbook Pro. C'est uniquement un backup!!!
« une Time Capsule, dans le mot de passe est le même que celui de ma session»
Avoir une timecapsule (ou un autre NAS) c'est tres bien.
Par contre le mot de passe doit etre different de celui de la session.
Ça vaut pour absolutment tout, la regle est simple :
1 identifiant => 1 mot de passe
jamais un meme mot de passe doit servir pour plusieurs comptes/identifiant/appareil. Un mot de passe doit etre unique a un usage, un appareil!!!!
Pour en revenir au bug en question: c'est donc bien que que l'on etait plusieurs ici a avoir suspecté et denoncé, et il est donc gravissime, et releve surtout d'un probleme de fond structurel et manageriale chez Apple, et demontra aussi une faiblesse majeure du controle qualité et de la stategie de developpement actuelle. Jamais un tel bug n'aurait du se retrouver dans une version mise sur le marché. Cela demontre, comme d'autres avant, qu'Apple a un tres gros probleme au niveau de la conception et de l'organisation, surtout au niveau du Mac... ce qui tend a montrer une fois de plus aussi qu'il n'y a pas de ressources exclusivement dédiées au Mac!
@C1rc3@0rc : je ne comprends pas ta réponse concernant le boot via un disque externe cloné par CCC sous iOS 10.13 (APFS chiffré) : ça marche très bien à partir d’un clone stocké en HFS+ Chiffré.
Il te suffit de tester, non ?
Et pendant ce temps là le bug ICONSERVIRCEAGENT qui bouffe ma RAM avec le kernel , n’est toujours pas corrigé dans la dernière beta 2 je n’en peux plus ???.
Quelqu’un peut être sais comment purger les photos que j’ai mis dans la petite vignette en haut à droite quand ont fait « commande i , je ne sais pas si j’ai bien expliqué mais voila mon problème :
J’ai une grosse bibliothèque sur un disque dur externe usb3 ou j’ai mis pour chaque fichier une photo pour repérer plus vite lesdites fichiers quand j’ouvre le disque dur badaboum ... ICONESERVICEAGENT se met a bouffer toute ma RAM et en quelques minutes mon MAC ne répond plus, donc impossible pour moi d’utiliser mon disque dur et les fichiers qui sont dedans , si quelqu’un a une solution je suis preneur.
Je précise que j’ai essayé sur un autre MAC resté lui sur sierra et mon disque dur affiche parfaitement toute les informations comme il se doit .
«Je précise que j’ai essayé sur un autre MAC resté lui sur sierra et mon disque dur affiche parfaitement toute les informations comme il se doit .»
solution a tous les problemes => rester sur MacOS 10.12 ou 10.11 et eviter comme la peste MacOS 10.13 "High Sierra"!!!
Dans la note d'Apple il est indiqué :
Les volumes APFS chiffrés que vous avez créés à l’aide de toute autre méthode ne sont pas concernés.
Cela veut-il dire que l'on a rien à faire pour le volume de démarrage du Mac chiffré via FileVault ?
@kubernan
Lorsque tu as le mot de passe qui est demandé, tape n'importe quoi jusqu'a ce que tu ais l'aide qui t'affiche normalement l'indice du mot de passe.
Si a la place de l'indice tu vois ton mot de passe, faut:
1) faire un backup
2) effacer le disque
3) chiffrer le disque
4) reinstaller les données.
Dans le cas ou ce qui est affiché c'est l'indice et pas le mot de passe, non il n'y a rien a faire, tout va bien (enfin pour le moment jusqu'a ce qu'un nouveau bug de 10.13 apparaisse)
@C1rc3@0rc : merci pour ta réponse. J’ai appliqué le mise à jour. De toute façon l’indice qui s’affiche est bien un indice.
L'extrait de ces codes est intéressant sur au moins deux points:
1. On demande aux développeurs de passer de l'Objective-C à Swift alors que les ingénieurs chez Apple poursuivre le développement dans ce soit disant langage has been.
2. La routine objc_msgSend permettant la transmission d'arguments n'est plus autorisée depuis au moins 10.11. Xcode oblige à recourir aux méthodes performSelector pour des raisons de sécurité. Le problème est qu'aucune méthode n'est proposée pour plus de deux arguments !
@eric210766
L'exemple parfais du faites ce que je dis, pas ce que je fais et du laisser aller d'Apple concernant le Mac particulièrement (on fait le minimum pour que ça fonctionne au minimum avec un minimum de nouvelles fonctions - implémentées au minimum- qui requièrent un minimum de développeurs) !
Désolé, mais je ne comprends rien à ce que tu/vous dis/dîtes !
@ eric210766 :
Les appels à objc_msgSend apparaissent ici parce que ce qu'on voit est le résultat d'une décompilation, et non le code source d'origine.
« Le problème est qu'aucune méthode n'est proposée pour plus de deux arguments ! »
Il y a (et il y a toujours eu) NSInvocation pour ce cas.
Certes, c'est plus long à écrire. Mais il y a bel et bien quelque chose de proposé pour gérer ce cas.
@ BeePotato
Concernant les appels à objc_msgSend, je disais simplement qu'auparavant il était possible de l'utiliser avec un nombre d'arguments quelconques. Il suffisait de transmettre nil pour le dernier.
En ce qui concerne NSInvocation, c'est effectivement une autre solution qui existait bien avant l'abandon de objc_msgSend. Le principal problème n'est pas l'augmentation du nombre de lignes mais plutôt au niveau des performances.
[EDIT]
Il est vrai que le code ressemble à une décompilation. Par contre, je ne vois pas l'intérêt de travailler sur ce type de source sachant que l'original appartient à Apple !
@ eric210766 : « Le principal problème n'est pas l'augmentation du nombre de lignes mais plutôt au niveau des performances. »
Ah, ça… Ok, je vois.
« Il est vrai que le code ressemble à une décompilation. »
Ben oui. Il fait plus qu'y ressembler : le gusse sur son blog explique clairement que c'est ça.
« Par contre, je ne vois pas l'intérêt de travailler sur ce type de source sachant que l'original appartient à Apple ! »
??
Qui parle de travailler dessus ?
Ce gars était juste curieux de vérifier ce qui avait changé entre les deux versions, histoire de confirmer l'hypothèse qui paraissait évidente à tout le monde. Rien de plus.
@BeePotato
OK, j'ai été un peu vite en besogne sur cette déclaration, c-à-d à propos de la section EDIT!
@eric210766
Très bonne idée de réécrire les millards de lignes de code d’un système d’exploitation dans un langage qui brise ses sources tous les ans ou deux ans, tu es un vrai génie toi
@ Mrleblanc101
Désolé, mais je ne comprends pas. Que veux-tu dire ?
@ eric210766 : « 1. On demande aux développeurs de passer de l'Objective-C à Swift alors que les ingénieurs chez Apple poursuivre le développement dans ce soit disant langage has been. »
Au fait, j'y pense seulement maintenant, mais le fait que des appels à objc_msgSend apparaissent dans le code décompilé n'indique pas forcément que le code source était écrit en Objective C.
Si je ne m'abuse, il aurait tout aussi bien pu être écrit en Swift, mais à partir du moment où il utilise un NSDictionary ça passera par du objc_msgSend, n'est-ce pas ?
@BeePotatoo
Il me semble que lors de la sortie de Swift, l'argument de vente était que ce nouveau langage apportait des gains importants par rapport à l'Objective-C au niveau des exécutables. Pour obtenir ce genre de performance, les runtimes ne peuvent qu'être différents et je vois mal l'intérêt de reprendre du code intermédiaire commun alors qu'aux deux extrêmes tout est différent (language-exécutable).C'est dans ce contexte que j'avais fait cette remarque.
@ eric210766 : « Il me semble que lors de la sortie de Swift, l'argument de vente était que ce nouveau langage apportait des gains importants par rapport à l'Objective-C au niveau des exécutables. »
En fait, l'argument principal porte sur la facilité d'écriture et la sécurité renforcée, bien plus que sur les performances.
« Pour obtenir ce genre de performance, les runtimes ne peuvent qu'être différents et je vois mal l'intérêt de reprendre du code intermédiaire commun alors qu'aux deux extrêmes tout est différent (language-exécutable). »
Quand on fait appel, depuis un programme en Swift, à une bibliothèque écrite Objective C (donc tout Cocoa), c'est le runtime Objective C qui est utilisé pour exécuter cette partie.
Pour les parties en pur Swift, on ne verra pas d'appel à objc_msgSend.
@ eric210766
Ce n'est pas le code source qui est affiché, mais le résultat de rétro-engineering, le code source correspondant au résultat compilé.
Sans analyser le code, je pense qu’à peu près n’importe quel développeur se doutait fortement de l’origine du bug.
@ minipapy : « Sans analyser le code, je pense qu’à peu près n’importe quel développeur se doutait fortement de l’origine du bug. »
Tout à fait.
Mais il y en avait tout de même, parmi les commentateurs, pour être convaincus que l'explication ne pouvait pas être aussi simple et qu'il s'agissait forcément d'un problème de conception d'APFS (ou autre scénario catastrophe du même acabit).
@ minipapy
Oui, mais quand on se rend compte du niveau d’incompétence de toute la chaine pour que ce bug arrive sur un OS largué dans le grand public, on s'attend a absolument tout et meme pire.
L'hypotese du mot de passe embarqué dans le volume chiffré, hypothese ridicule auxquels certains ici s'accrochaient (et qui permettait d’éviter de considérer la réalité et de l'\ampleur de la bêtise commise) aurait quand meme aussi pu exister vu le niveau de connerie de la chaine en question.
La gravité du bug est aussi enorme que celle du "bug de l'an 2000" dont avait ete affligé iOS. C'est vraiment une catastrophe et Apple doit au minimum revoir l'integralité de sa politique de developpement et de securité.
@ C1rc3@0rc : « L'hypotese du mot de passe embarqué dans le volume chiffré, hypothese ridicule auxquels certains ici s'accrochaient (et qui permettait d’éviter de considérer la réalité et de l'\ampleur de la bêtise commise) »
C'est fabuleux de voir à quel point tu peux en arriver à retourner les choses juste pour pouvoir caser tes prédictions de fin du monde.
L'hypothèse d'une approche complètement foireuse du chiffrage de volumes APFS permettait d'éviter de considérer l'ampleur d'une petite erreur ridicule ??? Vraiment étrange, comme idée.
« aurait quand meme aussi pu exister vu le niveau de connerie de la chaine en question. »
Non, ça n'a rien à voir.
Le processus qui laisse passer une erreur d'implémentation telle que celle qu'on a vue n'est pas le même que celui qui laisserait passer une énorme erreur de conception.
@ C1rc3@0rc
Intéressant.
Donc le "bug de l'an 2000" aurait "affligé iOS" sorti sept ans plus tard en 2007 ?
MDR
J’avais dit dans les commentaires que ça devait être ça. Rien que parce que le mot de passe n’est pas stocké en clair et ne peut pas être récupéré.
J'adore le blog cité dans l'article.
Sur ce blog :
- premier post en décembre 2014 pour dire : coucou j'ouvre mon blog
- deuxième post en octobre 2017 pour indiquer "ce bug".
Bravo à celle ou celui qui a trouvé le premier cette "info" sur ce blog très actif !
Les autres posts etaient peut-être stockés sur un volume Apfs chiffré ?
Au sujet de l'article : il y a une petite erreur dans la légende des images montrant le code avant/après.
Dans le code « avant », ce n'est pas la ligne en vert qui est la cause du bug, mais la ligne 92 (où on voit que la même valeur est utilisée pour l'indice que deux lignes plus haut pour le mot de passe).
Et de la même façon, dans le code « après », ce n'est pas la ligne en rouge qui corrige le bug, mais la ligne 94 (où on peut voir que, cette fois, ça ne reprend pas la même valeur que pour le mot de passe).
Avec tout ça, je voudrais bien comprendre : si on a fait une clean install de High Sierra, on n'a rien à craindre pour son mac? Il s'agit de volumes extérieurs seulement?
@ LNB691
Si tu n'as pas utilisé l'utilitaire de disque pour ajouter manuellement une partition APFS cryptée, alors tu ne crains rien.
Sinon il y a la méthode dite de Saint Thomas (je ne crois que ce que je vois) : Comme dit plus haut, fait en sorte que ton indice soit affiché, et vérifie qu'il ne s'agit pas de ton mot de passe en clair.