Safari a été pendant plus de cinq ans sensible à une faille de sécurité zombie, qui avait été éliminée en 2013 avant de se revenir à la vie en 2016.
L'équipe Project Zero de Google, en charge de découvrir des vulnérabilités zero day, est revenue sur l'histoire d'une faille de sécurité qualifiée de « zombie » touchant le navigateur Safari, et donc les appareils Apple.
Le patch de 2013 n'a pas suffi
Il s'agit de la vulnérabilité connue sous le nom de CVE-2022-22620, qui a obtenu un score de gravité de 8,8/10 selon le barème CVSS. Elle exploitait des faiblesses dans WebKit, une plateforme conçue par Apple qui propose aux développeurs des outils liés à l'intégration d'un moteur de rendu de pages web dans un navigateur.
La faille de sécurité concerne plus particulièrement l'API History de WebKit. Elle permettait aux hackers d'injecter et d'exécuter du code arbitraire à des fins malveillantes et a pu être activement exploitée, selon les aveux d'Apple même.
Ce qui est étonnant dans le cas de cette vulnérabilité, c'est qu'elle a été originellement identifiée et corrigée par Apple dès 2013… avant de faire son retour, d'où le sobriquet de « zombie » accordé par les chercheurs de Project Zero.
Une faille qui a pu être exploitée de décembre 2016 à janvier 2022
D'après Maddie Stone, l'une des expertes qui ont découvert la faille, une variante de celle-ci est réapparue trois ans après sa correction, en 2016. L'attaque a recours aux mêmes bugs que l'ancienne version, mais elle emprunte des chemins différents pour appuyer là où ça fait mal. Le code a également été modifié pour contourner les protections mises en place par Apple.
Pendant plus de cinq ans, Safari était donc sensible à cette faille de sécurité de deuxième génération. Apple a finalement publié une mise à jour sur Safari, iOS, iPadOS et macOS au mois de février 2022 pour s'en débarrasser, on espère définitivement cette fois-ci.
L'auteure de l'article détaillant ce cas dédouane les équipes d'Apple de toute responsabilité, admettant qu'il n'y a pas de réponse facile à ce qui aurait dû être fait différemment et que les développeurs qui ont corrigé la faille en 2013 ont « suivi de nombreuses bonnes pratiques »
Ils avaient notamment corrigé toutes les manières de déclencher la vulnérabilité, pas seulement le chemin utilisé pour la preuve de concept. Ils avaient également bien expliqué dans les commits la nature de la faille et la manière dont ils allaient la réparer.
Source : Project Zero
