Des chercheurs de Google détaillent une vulnérabilité Apple Safari de 5 ans exploitée à l’état sauvage


Une faille de sécurité dans Apple Safari qui a été exploitée dans la nature plus tôt cette année a été initialement corrigée en 2013 et réintroduite en décembre 2016, selon un nouveau rapport de Google Project Zero.

Le problème, suivi en tant que CVE-2022-22620 (score CVSS : 8,8), concerne un cas de vulnérabilité d’utilisation après libération dans le composant WebKit qui pourrait être exploitée par un élément de contenu Web spécialement conçu pour obtenir l’exécution de code arbitraire.

Début février 2022, Apple a envoyé des correctifs pour le bogue sur Safari, iOS, iPadOS et macOS, tout en reconnaissant qu’il “peut avoir été activement exploité”.

La cyber-sécurité

“Dans ce cas, la variante a été complètement corrigée lorsque la vulnérabilité a été initialement signalée en 2013”, a déclaré Maddie Stone de Google Project Zero. a dit. “Cependant, la variante a été réintroduite trois ans plus tard lors d’importants efforts de refactorisation. La vulnérabilité a ensuite continué d’exister pendant 5 ans jusqu’à ce qu’elle soit corrigée comme un jour zéro dans la nature en janvier 2022.”

Alors que les deux 2013 et 2022 bogues dans le API d’historique sont essentiellement les mêmes, les chemins pour déclencher la vulnérabilité sont différents. Ensuite, les modifications de code ultérieures entreprises des années plus tard ont ravivé la faille du jour zéro comme un “zombie”.

La cyber-sécurité

Déclarant que l’incident n’est pas propre à Safari, Stone a en outre souligné qu’il fallait suffisamment de temps pour auditer le code et les correctifs afin d’éviter les cas de duplication des correctifs et de comprendre les impacts sur la sécurité des modifications apportées.

“Les commits d’octobre 2016 et de décembre 2016 étaient très volumineux. Le commit d’octobre a modifié 40 fichiers avec 900 ajouts et 1225 suppressions. Le commit de décembre a modifié 95 fichiers avec 1336 ajouts et 1325 suppressions”, a noté Stone.

“Il semble intenable pour les développeurs ou les réviseurs de comprendre en détail les implications en matière de sécurité de chaque modification de ces commits, d’autant plus qu’elles sont liées à la sémantique de la durée de vie.”



ttn-fr-57