Fermer le menu
 

High Sierra : explications sur le bug de mot de passe des volumes APFS chiffrés

Stéphane Moussie | | 18:16 |  36

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.

« toto » n’est pas l’indice, mais le mot de passe……

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.

En vert, la ligne de code responsable du bug.
En rouge, la version corrigée.

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.

Catégories: 

Les derniers dossiers

Ailleurs sur le Web


36 Commentaires Signaler un abus dans les commentaires

avatar bonnepoire 10/10/2017 - 18:27

N’empêche si la variable avait été celle de l’indice ça aurait vraiment été la merde

avatar fornorst 10/10/2017 - 18:34 via iGeneration pour iOS

Le bug aurait sûrement été vu bien avant :)

avatar DDivo 10/10/2017 - 18:42 via iGeneration pour iOS

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



avatar Moonwalker 10/10/2017 - 19:06

Non.

On parle ici des volumes chiffrés créés à l’aide de l’utilitaire de disque avant correction du bug.

avatar C1rc3@0rc 11/10/2017 - 00:51

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

avatar kubernan 11/10/2017 - 02:40

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

avatar nemrod 12/10/2017 - 12:59

Il te suffit de tester, non ?

avatar Alberto8 10/10/2017 - 18:43 via iGeneration pour iOS

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 .

avatar C1rc3@0rc 11/10/2017 - 00:53 (edité)

«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"!!!

avatar kubernan 10/10/2017 - 19:03

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 ?

avatar C1rc3@0rc 11/10/2017 - 00:57 (edité)

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

avatar kubernan 11/10/2017 - 02:33 (edité)

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

avatar eric210766 10/10/2017 - 20:13

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 !

avatar mat 1696 10/10/2017 - 20:59 via iGeneration pour iOS

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

avatar eric210766 10/10/2017 - 21:06

Désolé, mais je ne comprends rien à ce que tu/vous dis/dîtes !

avatar BeePotato 10/10/2017 - 23:06

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

avatar eric210766 11/10/2017 - 08:40

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

avatar BeePotato 11/10/2017 - 11:07

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

avatar eric210766 11/10/2017 - 11:43

@BeePotato

OK, j'ai été un peu vite en besogne sur cette déclaration, c-à-d à propos de la section EDIT!

avatar Mrleblanc101 11/10/2017 - 00:14 via iGeneration pour iOS

@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

avatar eric210766 11/10/2017 - 08:11

@ Mrleblanc101
Désolé, mais je ne comprends pas. Que veux-tu dire ?

avatar BeePotato 11/10/2017 - 11:11

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

avatar eric210766 11/10/2017 - 11:51

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

avatar BeePotato 11/10/2017 - 17:55

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

avatar marc_os 11/10/2017 - 12:30 (edité)

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

Pages