Forcer le démarrage sur des périphériques Thunderbolt bloqués par macOS
Depuis l'arrivée de macOS 10.2.2 et de mises à jour de sécurité pour El Capitan et Yosemite (toutes sorties mi-décembre), il devient plus compliqué de démarrer sur certains périphériques Thunderbolt, souligne Le Journal du Lapin.
La raison n'en est pas un bug mais justement la correction d'une faille de sécurité présente dans le processus de démarrage de ces Mac. En branchant un périphérique Thunderbolt à son ordinateur et en le pilotant depuis un autre, on pouvait récupérer le mot de passe FileVault pour accéder au contenu chiffre de votre disque de démarrage.
L'EFI des Mac Thunderbolt, ce micro logiciel qui est chargé avant macOS, pouvait en effet laisser un logiciel malveillant envoyé par un périphérique Thunderbolt aller lire les données contenues dans la mémoire. Et par là, y trouver ce mot de passe stocké en clair. Ce n'est qu'à l'étape suivante, après le chargement de macOS, que le contenu de la mémoire est protégé contre de telles intrusions.
Apple a donc mis à jour l'EFI de ces machines de manière à empêcher le firmware d'un périphérique Thunderbolt d'entrer en action avant le chargement de macOS. Cela a cependant comme effet d'empêcher de démarrer sur un macOS installé sur ces supports de stockage.
Tous les périphériques de stockage ne sont heureusement pas placés à la même enseigne, tempère le Lapin. Ce sont surtout les boîtiers RAID, tels vendus par Promise qui peuvent être bloqués. Pour des matériels Thunderbolt plus classiques et dotés d'un seul disque dur ou SSD, l'EFI de ces Mac contient généralement les pilotes nécessaires pour un démarrage externe.
Une fiche technique d'Apple aborde (allez vers la fin) le cas de figure de ces périphériques qui ne sont plus bootables d'une manière automatique. On peut d'abord utiliser une combinaison de touches dans le gestionnaire de démarrage, tout au début du boot.
Mais ce sera vite fastidieux si l'on est amené à la répéter de nombreuses fois. Dans ce cas alors, il y a l'option de désactiver cette protection installée par Apple aux moyen d'une commande Terminal expliquée dans la fiche. Mais cela ne vaut que pour les Mac Thunderbolt du début 2015 (ou antérieurs) et il faut accepter de baisser la garde en termes de sécurité.
Il aurait peut être été plus propre de protéger la memoire du Mac dès l'allumage, plutôt que de devoir attendre que MacOS soit chargé pour prendre en charge cette protection, non?
Mais c'était peut être plus compliqué que de bloquer purement et simplement les périphériques Thunderbolt.
Mais si demain des périphériques USB présentent la meme faille de securite, Apple va aussi bloquer le boot sur périphérique USB?
Et après demain l'interface SATA pour les disques ou SSD non Apple qui pourraient être installés tout en embarquant un logiciel espion aspirant nos mots de passe?
Ca fait un peu solution de facilité cette façon de combler la faille, je trouve....
si vous laissez du code de bas niveau s'exécuter, il aura de toute façon le contrôle et pourra lire ce que vous saisissez au clavier.
C'est un problème classique entre flexibilité et sécurité.
Le mieux est de restreindre les périphériques.
-
et encore une fois, on voit que DMA est trop pernicieux pour être autorisés sans condition par des périphériques.
@oomu
Mais pourquoi pourrait-il le faire au démarrage et plus ensuite une fois MacOS chargé?
On ne peut pas avoir un firmware qui apporte le même niveau de protection de la memoire et du clavier que ce que réalise MacOS?
"Mais pourquoi pourrait-il le faire au démarrage et plus ensuite une fois MacOS chargé?"
parce que le but d'un port comme thunderbolt (mais pas que lui, Firewire aussi à son époque, et d'autres) est de fournir à la machine la possibilité de se voir ajouter des fonctionnalités de bas niveau via un périphérique.
Par exemple, justement, pouvoir booter l'ordinateur, pouvoir réagir à des événements matériels, pouvoir s'interfacer avec le bus pci, etc.
Apple pourrait programmer un firmware du mac qui tente de se protéger des intrusions des autres firmware chargé au boot. Mais fondamentalement, tout cela s'exécute dans des niveaux très bas du processeur. Le risque potentiel d'oublier la moindre interaction, effet de bord, est très grand.
(comme on l'a vu quantité de fois dans l'industrie en 40 ans)
Mieux vaut BRIDER : pas de code = pas de bug.
-
il est probable qu'une véritable solution pour faire la quadrature du cercle (protéger le boot de bas niveau customisé par des fabricants comme Apple tout en ouvrant aux périphériques de tierce partie) est dans les mains de à la fois Intel, Apple, les autres fabricants et mettra en jeu des variantes de trusting computing. et certifications.
La faille de sécurité ici n'est pas dans la possibilité de lire la mémoire par un pilote de firmware installé sur un périphérique Thunderbolt.
La faille de sécurité ici est que des données sensibles sont stockées en clair.
Il suffirait qu'elles soit stockées chiffrées et que la clé de déchiffrement soit elle stockée ailleurs, dans une partition cachée que seul le bootloader EFI de macOS sait comment trouver sa position, dans une puce à enclave sécurisée (hello T1 ?) ou sur l'iCloud, pour rendre nettement plus difficile l'exploit via un code EFI.
Résultat, ceux qui utilisent FileVault mais veulent booter depuis un disque externe vont désactivé cette protection, le risque de vol restera donc exactement le même qu'avant cette "protection", à la seule nuance que Apple pourra se déresponsabiliser sur le dos de ces clients.
@byte_order :
Mettre une info essentielle au démarrage dans le Cloud. En voilà une idée géniale ! Pas d'Internet, pas de boot.
mer il et fou !
d'où mon "ou".
Apple pousse bien, par défaut, les utilisateurs lambda à mettre leur documents - que ces utilisateurs mettent sur le bureau en grande majorité - dans iCloud.
Pas d'internet, boot okay... mais pas de documents. C'est guère mieux.
Le plus probable, c'est l'utilisation d'une enclave sécurisée de la puce T1 pour cela, j'imagine. Mais du coup cela concernera que les nouvelles machines. Pour les anciennes, une solution évitant l'écriture en clair pourrait déjà être un mieux, quand même.
Apple met en place le moyen de protéger les utilisateurs contre des logiciels malveillants il y en a qui trouve le moyen de contourner cet dite sécurité après sa va aller pleurnicher sur les forums parce QU' un intrus lui aura dérobé quelque mot de passe allé comprendre quelque chose
@DPOUND
Je crois que tu n'as pas bien compris les enjeux. On ne discute pas de la nécessité de combler une faille de sécurité, mais de la pertinence de la solution retenue par Apple.
Si certains périphériques Thunderbolt sont dotés de ROM optionnelle, c'est pas juste pour faire joli. Le fait d'en bloquer l'accès, s'il prévient d'un risque en cas de logiciel malveillant dans cette ROM, supprime des fonctionnalités de ces périphériques.
En conséquence, certains seront contraints de déverrouiller l'accès qu'a bloqué Apple pour utiliser leur matériel (d'ailleurs Apple donne le détail des 2 méthodes pour le faire).