Tout a changé, rien n'a changé

Un responsable de l’équipe Edge chez Microsoft s’est amusé à porter sur iOS un prototype du navigateur avec le moteur Blink, plutôt qu’en passant par le traditionnel (et obligatoire) WebKit. Résultat, une hausse significative des performances. Il ne s’agit toutefois pas d’un test réellement officiel, et les facteurs limitants n’ont pas changé.

Kyle Pflug est l’un des responsables produit d’Edge chez Microsoft. Dans une publication sur LinkedIn le 15 juin, il raconte un projet lancé le temps d’un week-end. Puisque le DMA en Europe permet aux éditeurs de navigateurs de fournir leur propre moteur sur iOS au lieu de passer par WebKit – normalement obligatoire – il s’est demandé ce que donnerait une version d’Edge effectivement accompagnée de Blink, comme sur ordinateur.

Les tests ont été effectués sur un iPhone 17 Pro Max sous iOS 26.5.1. Ils n’ont pas été poussés très loin, Pflug voulant une vue de synthèse sur la base de quelques benchmarks connus :

• Speedometer 3.1 (réactivité web) : 49,27 pour la version Blink, contre 38,3 pour la version WebKit, soit 28,6 % de mieux
• Jetstream 3 (JavaScript et WASM) : 306,35 pour la version Blink, contre 270,9 pour la version WebKit, soit 13,1 % de mieux
• MotionMark 1.3.1 (rendu graphique) : 4 773,52 pour la version Blink, contre 4 673,68 pour la version WebKit, soit 2,1 % de mieux

Comme il le raconte, il s’est amusé à entrer dans un Apple Store pour lancer les trois tests sur un iPad Pro M5. Les résultats étaient plus serrés, avec notamment 45,7 obtenus sur Speedometer. Mais les scores obtenus avec la version de test d’Edge restaient en tête.

Qu’en déduire ?

Difficile dans l’absolu de tirer de grandes conclusions, mais le cas souligne plusieurs points intéressants. Précisons quand même que Kyle Pflug indique bien qu’il s’agit d’une version de développement pour des tests personnels.

« Pour être clair, il s’agit d’un prototype de recherche, pas d’une annonce de produit. Et ce sont des chiffres préliminaires provenant de mon propre appareil, pas des résultats de laboratoire. Mais cela représente une opportunité de combler de véritables écarts de capacités et de susciter une nouvelle concurrence en termes de performance », écrit le responsable sur LinkedIn.

Le 16 juin, alors que Pflug publiait ses résultats sur Bluesky, le post a été repartagé par Ruck Byers, qui n’est autre que l’ingénieur en chef de Chrome chez Google. Il s’est dit impressionné, tout en lâchant une pique à Apple :

« Étant donné que Chromium et WebKit se disputent constamment la première place du classement Speedometer sur macOS, l’écart est vraiment frappant sur iOS ! Et nous n’avons même pas encore vraiment cherché à optimiser les performances pour cette plateforme ! À mon avis, c’est ce à quoi il faut s’attendre en l’absence de concurrence »

Pourquoi personne ne peut-il en profiter ?

Qu’est-ce qu’attend Microsoft pour sortir une version Blink d’Edge dans ce cas ? Ou même Google avec son Chrome ? N’ont-ils pas les moyens de se lancer ?

Techniquement, ils le peuvent. Depuis l’ouverture forcée par le Digital Markets Act de l’Union européenne, Apple a été obligée de lacher du lest. Mais Apple étant Apple, l’entreprise l’a fait d’une manière très particulière.

Ainsi, sur l’App Store, seuls des navigateurs basés sur WebKit (le moteur de Safari) peuvent être validés. Apple a toujours mis en avant la sécurité pour cette limitation : puisque tout le monde passe par le même moteur de rendu, Apple s’assure que ses sécurités sont les mêmes partout. Inévitablement, les performances sont à peu près égales partout aussi. Pour utiliser un autre moteur, il faut soit montrer patte blanche, soit passer par une boutique tierce, sachant que celles-ci ont du mal à se faire une place sur iOS à cause de multiples règles freinant leur développement.

• App Store : Apple détaille ses adaptations au DMA, des réactions déjà virulentes

Si l’on repart maintenant du cas d’Edge, que se passerait-il ? Il faudrait que Microsoft reparte de zéro et sorte un nouveau navigateur mobile pour iOS utilisant Blink. On ne parle pas d’un prototype, mais d’un produit fini, avec tout ce que cela suppose de tests et de finitions. Cette version pourrait soit être lancée sur l’App Store, avec un autre identifiant et en respectant le cadre BrowserEngineKit, soit sur une boutique tierce avec des règles plus libres.

Il y aurait donc deux versions d’Edge, dont une peut-être plus performante, mais accessible uniquement depuis une autre fiche ou un autre emplacement, dont la plupart des utilisateurs n’entendraient pas parler et qui n’existerait que dans l’Union européenne. Une proposition double qui ferait perdre en lisibilité. Et même en cas de boutique tierce, il faudrait d’abord installer cette dernière, ce qui réclame quelques manipulations. On est loin évidemment de la facilité d’installation depuis l’App Store, ou un bouton et une validation biométrique suffisent.

Rien n’a changé en deux ans

Comme le relève notamment The Register, la situation n’a guère évolué en deux ans malgré le DMA. L’ouverture forcée a engendré bien des navettes entre Apple et la Commission européenne, l’entreprise américaine ne cachant plus depuis longtemps sa détestation de cette réglementation.

Les critiques de Mozilla en janvier 2024, soit il y a près de deux ans et demi, sont toujours valables : « Nous sommes encore en train d’examiner les détails techniques, mais nous sommes extrêmement déçus par le plan proposé par Apple de restreindre le BrowserEngineKit nouvellement annoncé aux applications spécifiques à l’UE. Cela aurait pour effet de forcer un navigateur indépendant comme Firefox à construire et à maintenir deux implémentations de navigateur distinctes – un fardeau qu’Apple n’aura pas à supporter ».

Car oui, dans un tel système, Apple garde l’avantage de proposer simplement des mises à jour de son navigateur sans avoir à plier devant d’autres règles que les siennes. Safari et son moteur WebKit restent ainsi tout puissants sur iOS. BrowserEngineKit, créé pour permettre à d’autres moteurs de s’exprimer sur iOS, a des conditions trop restrictives pour être réellement utilisé.

Dans ce contexte, malgré une version de test, Mozilla n’a jamais donné suite à une version entièrement basée sur Gecko, le moteur attitré de la fondation. Le Firefox d’iOS est basé sur WebKit, comme les autres. Sortir une deuxième version ne serait pas rentable, forcerait une maintenance sur les deux moutures, avec une part de marché négligeable et pour laquelle il faudrait payer Apple, puisque « l’ouverture » consentie se fait aussi à travers une redevance.

Même Google avait travaillé sur une version Blink de Chromium pour iOS, comme l’entreprise l’avait confirmé en 2023. Depuis, rien ne s’est passé. Le test de Microsoft a cependant servi à remettre une pièce dans une machine silencieuse. L’association Open Web Advocacy a ainsi mené une nouvelle charge :

« Étant donné qu’Apple a eu plus de deux ans pour produire une solution conforme, la Commission européenne doit ouvrir une procédure de spécification pour instruire Apple, en termes précis, sur la manière dont ces obstacles doivent être levés. C’est, à notre avis, l’intervention la plus cruciale que l’UE puisse faire, et la plus susceptible de transformer l’ensemble de l’écosystème mobile. Aucune autre intervention ne s’en approche. »

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.

Rufus est une petite application très pratique qui permet de préparer des clés USB pour l’installation de systèmes d’exploitation. Elle s’est fait un nom avec Windows 11 en particulier, en incluant des options permettant de faire « sauter » les prérequis techniques, comme la présence obligatoire d’une puce TPM 2.0.

Quand la version 4.14 est sortie le 30 avril, elle a introduit une nouveauté majeure : l’installation silencieuse pour Windows 11. On peut ainsi paramétrer par avance tous les choix du processus, afin que l’installation se déroule d’une traite, sans intervention manuelle. On peut configurer ce que l’on souhaite comme configuration de stockage, créer un nouveau compte ou encore passer le premier assistant de configuration.

Cette version comportait cependant plusieurs problèmes. La mouture 4.15, disponible en bêta, en corrige la plupart, notamment deux importants : un blocage qui pouvait survenir à 75 % de l’installation, ou encore un autre qui entrainait un plantage au démarrage sur les machines ARM64 équipées d’une puce Snapdragon X. L’utilisation d’une image ISO contenant plusieurs conteneurs WIM pouvait également déclencher une boucle de redémarrage sans fin.

Dans les notes de version, on peut voir que les garde-fous autour de cette fonction d’installation silencieuse ont été améliorés. En outre, il est maintenant possible d’annuler l’opération si des erreurs d’écritures sont rencontrées.

On peut récupérer cette bêta depuis le dépôt GitHub de l’application. Les plus prudents attendront cependant l’arrivée de la version finale.