Safari : Une 0-Day WebKit critique découverte
Charles Gouin-Peyrot
Publié le 21 juin 2022 · 2 min de lecture
"Dans ce cas, la variante a été complètement corrigée lorsque la vulnérabilité Safari a été initialement signalée en 2013", a déclaré Maddie Stone du Google Project Zero. "Cependant, la variante a été réintroduite trois ans plus tard lors d'importants efforts de refactoring. La vulnérabilité a ensuite continué à exister pendant 5 ans jusqu'à ce qu'elle soit corrigée en tant que zero-day in-the-wild en janvier 2022."Si les bogues de 2013 et 2022 dans l'API d'historique sont essentiellement les mêmes, les chemins pour déclencher la vulnérabilité sont différents. Les modifications ultérieures du code entreprises des années plus tard ont fait renaître la faille zero-day d'entre les morts comme un "zombie"." Voici le Proof of Concept :
Indiquant que l'incident n'est pas unique à Safari, Stone a de plus souligné qu'il fallait prendre le temps nécessaire pour auditer le code et les correctifs afin d'éviter les cas où il faut reproduire les corrections et comprendre les impacts de sécurité des changements effectués.
" Les commits d'octobre 2016 et de décembre 2016 étaient tous deux 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 tout développeur ou réviseur de comprendre en détail les implications de sécurité de chaque changement dans ces commits, en particulier parce qu'ils sont liés à la sémantique de la durée de vie."
L'auteur
Charles Gouin-Peyrot
Journaliste tech et testeur indépendant, je décrypte la tech grand public. Spécialisé dans le hardware, l'audio et la maison connectée, je mets ma rigueur technique et mon expérience de formateur au service de mes tests. Mon objectif est simple : dépasser les fiches techniques pour vous livrer des analyses transparentes, impartiales et ancrées dans un usage 100 % réel.