C’était une promesse sur laquelle Adobe était attendu au tournant : mieux sécuriser son lecteur Adobe Reader. Ce dernier est en effet devenu un vecteur privilégié d’attaques à travers des documents PDF piégés. Certes, c’est avant tout l’usage de Javascript par le format PDF qui est incriminé et d’autres lecteurs que ceux d’Adobe ont eux aussi déjà été mis en cause de la sorte. Mais tel est le lot du chef de file : il est à la fois le plus attaqué et le plus critiqué (demandez donc à Microsoft !).

Avec l’annonce de son Reader X Adobe concrétise ainsi aujourd’hui la promesse faite en juillet dernier d’intégrer un bac à sable à son lecteur : c’est le « mode protégé » (à ne pas confondre avec la fonctionnalité du même nom présente dans les processeurs x86). Ici la technologie s’inspire plutôt du bac à sable développé par Google pour son navigateur Chrome ainsi que du « Protected Viewing Mode » de Microsoft Office 2010 (d’ailleurs les équipes de développement de ce dernier ont participé à la définition du bac à sable d’Adobe).

L’objectif est de réaliser toutes les opérations d’affichage du PDF au sein d’un environnement isolé du reste du système, et de soumettre les demandes de « sortie » du bac à sable à un mandataire qui lui seul aura accès au système de l’utilisateur. Ce dernier repose sur un mécanisme de communication inter-processus (IPC) et fonctionne selon le principe de la liste blanche : ce qui n’est pas spécifiquement autorisé sera interdit par défaut.

Une courte liste d’actions est pré-autorisée, par exemple écrire dans le répertoire TMP de l’utilisateur ou ouvrir un document .docx dans Microsoft Word). Pour le reste des règles sont configurables à travers une syntaxe relativement claire. La règle AddRule(SUBSYS_FILES, FILES_ALLOW_READONLY, L”c:\\temp\\app_log\\*.log”) autorisa par exemple l’application Reader à accéder en lecture seulement à un dossier spécifique, et uniquement aux fichiers dotés de l’extension .log.

Pour autant Adobe n’a pas choisi une isolation parfaite telle que le recommandent pourtant les puristes. Il est en effet préférable de placer le bac à sable dans une entité (un desktop) totalement distinct afin d’éviter plusieurs attaques connues, dont les fameuses « shatter attacks« . L’éditeur assume et s’en explique de manière imagée (« cela aurait représenté une tâche titanesque, un peu comme ajouter un rez-de-chaussé à un immeuble de vingt étages après sa construction« ).

Cela ne l’empêche toutefois pas d’en être conscient et de promettre avoir travaillé à des solutions annexes, destinées dit-il à mitiger les principales attaques envisageables lorsque les desktops ne sont pas séparés (outre les attaques shatter on recense également l’injection de DLL via la fonction SetWindowsHookEx). Leur efficacité reste toutefois à prouver…

La documentation de Adobe laisse en tout cas au non-spécialiste une impression d’effort sincère et de réflexion pertinente en matière d’architecture. La démarche qui consiste à ne pas ré-inventer la roue mais plutôt d’aller demander de l’aide aux confrères déjà confrontés au même problème (Google et Microsoft ici) est également louable. Mais nous laissons aux experts de la communauté SecurityVibes le soin de disséquer la documentation officielle et de nous rassurer sur l’effort d’Adobe !

Accéder à documentation : http://blogs.adobe.com/asset/2010/11/adobe-reader-x-is-here.html