Selon une ancienne ingénieure en sécurité d'Apple, l'entreprise de Cupertino a laissé passer trois semaines entre le patch corrigeant une vulnérabilité dans Safari sous Mac OS X et le correctif pour la même vulnérabilité dans Safari sous iOS, exposant les utilisateurs de son système d'exploitation mobile à des problèmes de sécurité connus. La chercheuse en sécurité Kristin Paget, qui a quitté Apple fin janvier pour rejoindre Tesla Motors, a vivement critiqué la politique de livraison de correctifs pratiquée par son ancien employeur dans un billet publié mercredi sur son blog. Elle souligne que la plupart des vulnérabilités corrigées dans iOS 7.1.1 par le patch livré mardi par Apple étaient identiques à celles corrigées le 1er avril dans les versions 6.1.3 et 7.0.3 de Safari pour Mac OS X. Un grand nombre de ces vulnérabilités affectaient le moteur de rendu web WebKit utilisé par iOS, le navigateur Safari et d'autres applications OS X. La plupart d'entre elles ont été identifiées par les membres de l'équipe de sécurité de Google Chrome.

Des retards récurrents chez Apple

Selon l'avis de sécurité publié par Apple pour iOS 7.1.1, certaines failles découvertes dans WebKit peuvent permettre à un attaquant d'exécuter du code arbitraire quand les utilisateurs accèdent à des sites web malveillants. « Apple se targue d'utiliser le même kernel (plus un mélange de composants divers) pour ses deux plates-formes [iOS et OS X], mais il ne corrige qu'un système à la fois, exposant les utilisateurs de l'autre plate-forme à des failles de sécurité connues pendant plusieurs semaines », a déclaré Kristin Paget. « Comment peut-on accepter cela ? Il semble qu'Apple ait besoin que quelqu'un lui fasse écrire 100 fois : « Je n'exposerai pas les utilisateurs d'iOS à des failles Zero-Day identifiées dans OSX et réciproquement » », a-t-elle écrit.

Les failles dites Zero-day sont des vulnérabilités connues, mais pour lesquelles l'éditeur du produit concerné n'a pas fourni de correctif. « Des pirates peuvent très bien créer un programme d'attaque (exploit) à partir du correctif destiné à un produit et s'en servir pour attaquer d'autres produits et plates-formes pour lesquels la vulnérabilité n'est pas encore corrigée », a déclaré hier par courriel Carsten Eiram, chercheur pour l'entreprise de sécurité spécialisée Risk Based Security. Selon lui, ces retards de traitement entre les produits sont récurrents chez Apple, surtout quand il s'agit de corriger des vulnérabilités affectant WebKit. « Nous avons remarqué depuis longtemps que Google corrigeait les vulnérabilités de Chrome liées à WebKit bien avant qu'Apple ne le fasse pour ses produits », a déclaré Carsten Eiram. « Grosso modo, il peut se passer deux à trois mois en moyenne, et parfois beaucoup plus. Et depuis que Google a remplacé WebKit par Blink, cela semble être pire ».

Des failles corrigées avec un décalage de 5 à 6 mois

Google Chrome utilise le moteur de rendu WebKit jusqu'à la version 27. Mais, ensuite, le navigateur utilise un autre moteur appelé Blink, toujours basé sur WebKit. De ce fait, un grand nombre de problèmes trouvés et corrigés dans Chrome affectent aussi WebKit. Non seulement Apple prend son temps pour patcher le moteur WebKit lui-même, mais il prend aussi son temps pour intégrer les modifications dans tous ses logiciels basés sur WebKit.

Le chercheur de Risk Based Security fait remarquer par exemple que la faille WebKit identifiée sous la référence CVE- 2013-2909, a été corrigée dans Chrome le 1er octobre 2013. Apple a livré un correctif pour les versions 6.1.1 et 7.0.1 de Safari le 16 décembre 2013, soit deux mois et demi plus tard, le correctif pour iOS 7.1 a été livré le 10 mars, soit cinq mois plus tard, et celui pour l'Apple TV 6.1, le 22 avril, soit six mois et demi plus tard. « Le manque de coordination entre Google et Apple est une chose, mais il est étonnant de voir qu'Apple livre des correctifs pour patcher des vulnérabilités dans certains de ses produits et expose ses autres produits pendant une aussi longue période, et on ne peut qu'être en désaccord avec cette pratique. Il est inacceptable qu'Apple expose ainsi ses propres utilisateurs à des risques de sécurité connus ».