Critique local

Une faille de sécurité a été détectée dans les anciennes puces A12 et A13. Liée à l’architecture matérielle, elle ne peut pas être corrigée par une simple mise à jour logicielle, car elle s’appuie sur un bug dans le contrôleur USB.

La société européenne de cybersécurité Paradigm Shift a publié les détails d’une faille dans le BootROM (aussi appelé SecureROM) des puces Apple A12 et A13, accompagnée d’un exploit fonctionnel nommé « usbliter8 », rapporte MacRumors.

Le BootROM est le premier code exécuté par un iPhone à sa mise sous tension. Une vulnérabilité dans ce composant ne peut pas être corrigée par une mise à jour logicielle, car il est gravé directement dans la puce. Si ce type de faille vous rappelle des souvenirs, c’est qu’elle appartient à la même famille que checkm8, une faille matérielle rendue publique en 2019 et qui touchait déjà tous les iPhone du 4S au X.

Où réside la faille ?

La faille se trouve plus précisément dans le contrôleur USB des puces A12 et A13 (et dans une moindre mesure les puces S4 et S5 des Apple Watch). Lorsqu’un iPhone reçoit des données USB au démarrage, le contrôleur utilise un tampon mémoire (buffer) pour stocker les paquets entrants.

Paradigm Shift a découvert qu’en envoyant une séquence spécifique de paquets anormalement petits, il était possible de manipuler un pointeur matériel interne de façon à le faire « reculer » dans la mémoire, permettant l’écriture de données à des emplacements qu’il ne devrait jamais atteindre.

Les chercheurs précisent qu’il s’agit apparemment d’un bug du contrôleur USB matériel lui-même, et non du logiciel d’Apple, expliquant pourquoi aucun patch logiciel ne peut le corriger.

Grave à quel point ?

Seuls deux modèles de smartphones Apple sont touchés par cette faille : les iPhone XS et 11. La puce A11, qui équipait l’iPhone X, n’est pas touchée par cette « nouvelle » faille car son pilote USB réinitialise manuellement le pointeur après chaque paquet stocké dans le tampon. Les puces A14 et suivantes sont protégées car elles configurent correctement une fonctionnalité de protection mémoire au niveau du BootROM. Les A12 et A13 se retrouvent ainsi dans une zone intermédiaire vulnérable.

Selon la puce concernée, le niveau de difficulté diffère largement. Sur les appareils A12, obtenir l’exécution de code est relativement simple. Sur les appareils A13 en revanche, c’est beaucoup plus difficile car Apple a introduit le Pointer Authentication Code (PAC), qui détecte et bloque certains types de falsification de mémoire. Paradigm Shift indique qu’un processus complexe en plusieurs étapes a été nécessaire pour contourner le PAC sur l’A13 avant d’obtenir le contrôle du processeur.

Une fois le contrôle obtenu, l’exploit installe un gestionnaire personnalisé qui survit à un redémarrage de l’appareil et ajoute deux capacités : abaisser temporairement les paramètres de sécurité de l’appareil et lancer un logiciel non signé sans aucune vérification. Il injecte également la chaîne traditionnelle « PWND » dans le numéro de série USB de l’iPhone, signal de compromission qui reprend une convention héritée de checkm8.

Il s’agit d’une procédure locale, qui requiert une connexion USB et donc un accès physique. Elle ne peut pas être exploitée à distance, mais est quand même considérée comme critique par les chercheurs, car rien ne peut la corriger.

Un bug dans la correction

L’ironie veut que la nouvelle faille soit exploitable à cause des corrections apportées par Apple au mécanisme qui permettait à checkm8 de fonctionner en 2019. Cette correction a introduit un nouveau bug, qui permet aujourd’hui à usbliter8 de fonctionner, alors que l’iPhone X (puce A11) y est insensible par exemple.

Le bug et son exploitation peuvent-ils affecter la Secure Enclave des puces Apple, responsable (entre autres) du stockage des clés de sécurité ? Pas directement selon les chercheurs de Paradigm Shift. Une telle compromission du BootROM ouvre toutefois de nouvelles voies d’attaques contre ce composant crucial.

L’entreprise de sécurité indique dans son billet avoir averti Apple de ces problèmes avant la publication des résultats. Paradigm Shift affirme qu’il s’agit d’une divulgation coordonnée, en accord avec la firme de Cupertino.

Critique local

Une faille de sécurité a été détectée dans les anciennes puces A12 et A13. Liée à l’architecture matérielle, elle ne peut pas être corrigée par une simple mise à jour logicielle, car elle s’appuie sur un bug dans le contrôleur USB.

La société européenne de cybersécurité Paradigm Shift a publié les détails d’une faille dans le BootROM (aussi appelé SecureROM) des puces Apple A12 et A13, accompagnée d’un exploit fonctionnel nommé « usbliter8 », rapporte MacRumors.

Le BootROM est le premier code exécuté par un iPhone à sa mise sous tension. Une vulnérabilité dans ce composant ne peut pas être corrigée par une mise à jour logicielle, car il est gravé directement dans la puce. Si ce type de faille vous rappelle des souvenirs, c’est qu’elle appartient à la même famille que checkm8, une faille matérielle rendue publique en 2019 et qui touchait déjà tous les iPhone du 4S au X.

Où réside la faille ?

La faille se trouve plus précisément dans le contrôleur USB des puces A12 et A13 (et dans une moindre mesure les puces S4 et S5 des Apple Watch). Lorsqu’un iPhone reçoit des données USB au démarrage, le contrôleur utilise un tampon mémoire (buffer) pour stocker les paquets entrants.

Paradigm Shift a découvert qu’en envoyant une séquence spécifique de paquets anormalement petits, il était possible de manipuler un pointeur matériel interne de façon à le faire « reculer » dans la mémoire, permettant l’écriture de données à des emplacements qu’il ne devrait jamais atteindre.

Les chercheurs précisent qu’il s’agit apparemment d’un bug du contrôleur USB matériel lui-même, et non du logiciel d’Apple, expliquant pourquoi aucun patch logiciel ne peut le corriger.

Grave à quel point ?

Seuls deux modèles de smartphones Apple sont touchés par cette faille : les iPhone XS et 11. La puce A11, qui équipait l’iPhone X, n’est pas touchée par cette « nouvelle » faille car son pilote USB réinitialise manuellement le pointeur après chaque paquet stocké dans le tampon. Les puces A14 et suivantes sont protégées car elles configurent correctement une fonctionnalité de protection mémoire au niveau du BootROM. Les A12 et A13 se retrouvent ainsi dans une zone intermédiaire vulnérable.

Selon la puce concernée, le niveau de difficulté diffère largement. Sur les appareils A12, obtenir l’exécution de code est relativement simple. Sur les appareils A13 en revanche, c’est beaucoup plus difficile car Apple a introduit le Pointer Authentication Code (PAC), qui détecte et bloque certains types de falsification de mémoire. Paradigm Shift indique qu’un processus complexe en plusieurs étapes a été nécessaire pour contourner le PAC sur l’A13 avant d’obtenir le contrôle du processeur.

Une fois le contrôle obtenu, l’exploit installe un gestionnaire personnalisé qui survit à un redémarrage de l’appareil et ajoute deux capacités : abaisser temporairement les paramètres de sécurité de l’appareil et lancer un logiciel non signé sans aucune vérification. Il injecte également la chaîne traditionnelle « PWND » dans le numéro de série USB de l’iPhone, signal de compromission qui reprend une convention héritée de checkm8.

Il s’agit d’une procédure locale, qui requiert une connexion USB et donc un accès physique. Elle ne peut pas être exploitée à distance, mais est quand même considérée comme critique par les chercheurs, car rien ne peut la corriger.

Un bug dans la correction

L’ironie veut que la nouvelle faille soit exploitable à cause des corrections apportées par Apple au mécanisme qui permettait à checkm8 de fonctionner en 2019. Cette correction a introduit un nouveau bug, qui permet aujourd’hui à usbliter8 de fonctionner, alors que l’iPhone X (puce A11) y est insensible par exemple.

Le bug et son exploitation peuvent-ils affecter la Secure Enclave des puces Apple, responsable (entre autres) du stockage des clés de sécurité ? Pas directement selon les chercheurs de Paradigm Shift. Une telle compromission du BootROM ouvre toutefois de nouvelles voies d’attaques contre ce composant crucial.

L’entreprise de sécurité indique dans son billet avoir averti Apple de ces problèmes avant la publication des résultats. Paradigm Shift affirme qu’il s’agit d’une divulgation coordonnée, en accord avec la firme de Cupertino.

Une enquête de journalistes a mis au jour un vaste marché noir qui détourne des batteries usagées de voitures électriques pour les greffer illégalement sur des deux-roues. Ce qui n’est pas sans conséquence sur la sécurité des véhicules.

Prudence est mère de sûreté

Plusieurs certificats de sécurité utilisés par Microsoft et Linux pour Secure Boot arriveront à échéance cette année, dont une première vague le 27 juin. Nous faisons le point sur la situation, plus simple qu’il n’y paraît. Du moins si tout se passe bien.

Pour comprendre la situation, nous devons rappeler quelques points. Secure Boot est une fonctionnalité de sécurité du firmware UEFI dont l’objectif est d’empêcher l’exécution de code malveillant avant même que le système d’exploitation démarre, c’est-à-dire à un stade où les antivirus et autres protections logicielles classiques n’ont aucune visibilité. Les bootkits sont ainsi particulièrement dangereux, car ils s’exécutent avec un niveau de privilège supérieur à celui du système et survivent à une réinstallation complète de Windows ou Linux.

Le fonctionnement repose sur une chaîne de confiance cryptographique hiérarchisée :

1. La PK (Platform Key), détenue par le fabricant de la carte mère ou du PC et qui contrôle l’accès au niveau inférieur
2. La KEK (Key Exchange Key), utilisée pour mettre à jour les bases de signatures
3. La DB (Signature Database), qui liste les certificats de confiance autorisant tel ou tel bootloader à s’exécuter
4. La DBX (base de révocation), liste noire des signatures compromises qui bloque l’exécution de bootloaders connus comme vulnérables, même quand ils possèdent une signature valide

Pendant le démarrage, le bootloader vérifie chaque maillon de la chaine l’un après l’autre en comparant leur signature à celles présentes dans les bases mentionnées. Si l’une de ces signatures ne correspond pas ou fait partie de la liste de révocation, le firmware refuse le chargement du composant lié et interrompt le démarrage.

L’origine du problème

En 2011, Microsoft a établi trois certificats centraux : la Microsoft Corporation KEK CA 2011 pour la base KEK, la Microsoft Windows Production PCA 2011 pour les composants Windows signés, et la Microsoft Corporation UEFI CA 2011 pour les logiciels tiers, comme le rappelait Security Today en avril et Ars Technica le 17 juin.

Ces certificats disposaient d’une validité de 15 ans. Chacun a sa date d’expiration : les deux certificats Corporation (KEK et UEFI) expirent respectivement les 24 et 27 juin, le certificat Production court jusqu’au 19 octobre. Deux certificats vont donc expirer dans quelques jours, tandis que l’autre aura lieu dans quatre mois. Or, cette clé UEFI CA 2011, qui expire le 27 juin, est aussi utilisée pour la signature des bootloaders tiers, dont le « shim » de Linux, que les distributions peuvent utiliser pour se rendre compatibles avec Secure Boot.