Fin décembre une faille a été mise en évidence dans le lecteur de fichiers PDF (Adobe Reader et Adobe Acrobat Reader), que pratiquement tout le monde possède sur son ordinateur. Elle permet des attaques de type cross site scripting (XSS). Puis des spécialistes de sécurité ont réalisé ces jours-ci que la faille était potentiellement beaucoup plus grave que cela avait été d'abord envisagé.


au sommaire


    Logo d'Adobe Reader

    Logo d'Adobe Reader

    Les attaques par cross site scripting

    Les attaques de type XSS sont variées et peuvent être assez complexes. Pour faire bref elles reposent généralement sur plusieurs caractéristiques :

    • l'utilisation d'un langage de script, généralement Javascript ;
    • le fait qu'un site web puisse recevoir des données de la part d'un utilisateur (c'est le cas de très nombreux sites : achats en ligne, forums, blogs, sites d'information possédant un « courrier des lecteurs »ou talkback, webmails, sites bancaires, etc.)) ;
    • le site ne vérifie pas de façon stricte la conformité des données reçues (c'est malheureusement fréquent car les développeurs pensent d'abord à ajouter de nouvelles fonctionnalités sans toujours penser aux vulnérabilités qu'elles risquent d'introduire).

    Dans ces conditions un utilisateur malveillant peut attacher aux données qu'il envoie un script qui s'installera sur le serveur du site à l'insu de l'administrateur. Lors d'une consultation les autres utilisateurs ne verront pas le script mais celui-ci sera chargé et s'exécutera sur leur navigateur. Il peut alors en résulter des choses variées. Par exemple le script pourra afficher un popup induisant le lecteur en erreur car il le croira émis par le site qu'il consulte. Ou bien l'utilisateur pourra être détourné vers un site pirate imitant le site d'origine ; le site pirate pourra alors demander, sous un prétexte ou un autre, de confirmer le mot de passe pour accéder au compte personnel, le numéro de carte bancaire... (technique bien connue sous le nom de phishing). Enfin le script pourra détourner les paramètres de la session en cours (cookiecookie de session et autres informations) vers un site pirate. Si le pirate est à l'affût il pourra procéder à un vol d'identité et se faire passer pour l'utilisateur légitime pour effectuer des achats en ligne, des opérations bancaires, ou tout simplement poster dans un forum ou autre site un message compromettant qui semblera être écrit par l'utilisateur victime de l'opération.

     

    Ce type d'attaque est pratiquement imparable. Du côté du serveur le script malveillant est stocké dans les profondeurs de la base de donnée (parfois énorme) qui sert à construire les pages. Côté utilisateur les moyens de protection classiques ne sont d'aucune utilité : les pare-feupare-feu ne peuvent arrêter ce qui provient d'une page piégée, le script passe au travers d'un cryptage SSLSSL, l'immense majorité des antivirusantivirus et autres anti-malwaresmalwares ne détectent rien, ou alors trop tard.

    La faille d'Adobe Reader (première alerte)

    Cette vulnérabilité a été révélée lors de la conférence du Chaos Computer Club, fin décembre, au détour d'une communication de portée bien plus générale. Elle réside dans le fait que le pluginplugin autorise l'exécution de scripts qui seraient passés dans des liens piégés vers un fichier PDF.

    Or de très nombreux sites hébergent de tels fichiers et il est possible à un pirate, si les mesures de contrôle d'échange des paramètres n'ont pas été mises en œuvre au niveau du site, de piéger le lien vers ces fichiers. La consultation du fichier PDF par un visiteur pourra ouvrir la porteporte à toutes les nuisancesnuisances possibles du cross site scriptingcross site scripting : vol d'identité, phishing...

    La deuxième alerte

    Certains spécialiste de la sécurité se sont aperçus très récemment (3 janvier) que la faille était plus grave qu'on ne le pensait. En effet presque tout le monde possède Adobe Reader sur son ordinateurordinateur. Ce programme est livré avec, selon les versions, un ou plusieurs fichiers types (par exemple ENUtxt.pdf). Or on accepte pratiquement toujours le répertoire par défaut proposé lors de l'installation d'un programme. Il est ainsi facile de savoir où trouver un fichier PDF sur tous les ordinateurs.

    Donc si un script contenu dans un lien piégé fait référence à file:///C:/Program Files/.../ ENUtxt.pdf il sera capable de faire n'importe quoi sur n'importe quel ordinateur. Par exemple lire des fichiers, les effacer, les envoyer vers un l'ordinateur du pirate, exécuter des programmes... Ceci signifie donc que n'importe quel ordinateur hébergeant Adobe Reader est potentiellement vulnérable !

    Les risques et les solutions

    Tout d'abord il faut dire que cette vulnérabilité n'affecte que le plugin qui permet d'afficher les documents PDF dans le contexte du navigateur. Il n'y a aucun danger à afficher un document dans la version autonome d'Adobe Reader. Ceci suggère une première méthode de protection : télécharger le document sur son ordinateur et cliquer dessus pour le lire dans Adobe Reader sans passer par le navigateur. Ceci peut être assuré dans Firefox et Opera en supprimant l'ouverture dans le plugin (Firefox : Outils, Options, Type de fichiers, Gérer ; Opera : Outils, Préférences, Avancé, Téléchargement, sélectionner ApplicationApplication/PDF et cliquer sur Éditer). Sinon on peut faire un clic droit sur le lien et choisir d'enregistrer la cible.

    D'autre part le risque n'est pas obligatoirement le même selon le navigateur et sa version, les solutions de sécurité intégrées dans le navigateur pouvant éventuellement limiter certains aspects du risque. Il semble bien qu'au niveau d'Adobe tous les aspects potentiels de cette faille soient encore en cours d'investigation. L'éditeur conseille de passer à la version 8 (qui ne présente pas cette faille) disponible depuis le mois dernier, mais cette version occupe 118 Mo sur le disque (rédhibitoire si on utilise une connexion RTCRTC) ! Adobe pense pouvoir fournir un correctif pour les versions précédentes d'ici peu.

    Finalement cette vulnérabilité n'est qu'un exemple de plus dans la grande catégorie qui utilise la possibilité d'introduire dans certains champs de saisie autre chose que ce pour quoi il est prévu : on a de nombreux exemples d'utilisation de requêtesrequêtes, d'URL ou de chaînes de caractères mal formés... sauf que d'habitude cela conduit à des erreurs du type dépassement de mémoire tamponmémoire tampon qu'il faut ensuite exploiter. Tandis qu'ici on introduit directement un script qui s'exécute gentiment sans rencontrer le moindre obstacle.

    Il faudrait que les programmeurs pensent davantage à contrôler systématiquement la validité des données saisies et qu'ils se demandent d'abord comment la fonction qu'ils codent peut être détournée. Or on introduit trop fréquemment des fonctionnalités en vérifiant uniquement si elles marchent et on mobilise ensuite des équipes spécialisées pour boucher (souvent trop tard) les trous que les concepteurs ont négligés. La complexification croissante liée a l'émergenceémergence de techniques (largement à base de scripts) englobées sous le vocable de Web 2 laisse augurer de beaux jours pour les pirates de tout poil.