Billy Rios, ingénieur de sécurité chez Google, a publié sur son blog personnel un moyen de contourner le « bac à sable » proposé récemment par Adobe. Cette méthode permet aux fichiers Shockwave Flash (SWF) d'être lus comme en local, mais de ne pas envoyer des données sur le réseau. Il empêche également les fichiers SWF de faire appel à des JavaScript ou des requêtes HTTP ou HTTPS, souligne le chercheur. Un fichier local correspond à celui qui utilise "file : protocole" ou un chemin référencé par la Convention Universel de nommage (Universal Naming Convention), poursuit Billy Rios.

Mais il a constaté que toutes les restrictions du « bac à sable » ne sont pas aussi rigides. Il a découvert un moyen de contourner la sandbox, en reformulant une requête du type file://request to a remote server. Adobe a toutefois limité ces requêtes à des adresses IP en local et en fonction du nom des machines, relativise Billy Rios. Adobe a intégré une liste noire sur certains gestionnaires de protocole, mais pas tous, une méthode que le chercheur considère comme dangereuse et d'ajouter « si on peut trouver un gestionnaire de protocole qui n'a pas été référencée par Adobe et qui se connecte au réseau, c'est gagné ».

Il prend comme exemple le protocole « mhtml », qu'exploite Outlook Express installé sur les systèmes Windows et qui n'est pas recensé par Adobe dans sa liste noire. Ainsi, un fichier SWF peut exporter des données en utilisant une requête par ce protocole, a détaillée Billy Rios dans son blog. Il souligne que cette procédure est particulièrement efficace car, si la requête échoue, les données seront toujours transmises au serveur de l'attaquant sans que la victime le sache. Il tire donc deux leçons de cette expérience: « l'exécution de code SWF non fiable est dangereux et que les listes noires de gestionnaire de protocole sont mauvaises si incomplets ».

Une faille peu critique selon Adobe

Une porte-parole d'Adobe a indiqué l'éditeur a analysé les travaux de Billy Rios et a confirmé un bug, en le classant comme un risque «modéré» dans son échelle de gravité. « Un hacker doit d'abord accéder au système de l'utilisateur et placer un fichier SWF malicieux dans un répertoire sur la machine locale avant de pouvoir tromper l'utilisateur en lançant une application qui exécutera le fichier SWF en mode natif » écrit-elle dans un e-mail. Elle ajoute « dans la majorité des scénarios d'utilisation, le fichier SWF malveillant ne pouvait pas simplement être lancé en double-cliquant dessus. L'utilisateur devra ouvrir manuellement le fichier depuis l'application elle-même ».

Adobe et Google ont travaillé ensemble sur l'amélioration de la sécurité dans Flash. Le mois dernier, les deux sociétés ont dévoilé aux développeurs la première version de Flash qui utilise ce système de bac à sable. Il fonctionne sur le navigateur Chrome de Google sur les OS Windows XP, Vista et 7. Adobe utilise également une sandbox dans son Reader PDF X, produit, qui a été publié en novembre.