La réputation ne fait pas tout. Et, comme à l’accoutumée, Mac OS X n’a pas manqué de faillir lors de la dernière édition du concours Pwn2Own, lors de CanSecWest. Cette fois-ci, ce sont les Français de Vupen Security qui ont réussi à trouver et exploiter une faille de WebKit, le moteur de rendu HTML de Safari.

Il faut dire que Vupen s’est fait une spécialité de ce qu’il convient d’appeler «l’intrusion amicale» ou, autrement dit, le test de pénétration. Parmi les clients de Vupen Security, on compte notamment Microsoft, Shell, Sagem ou encore l’IGN. Leur métier, c’est la mise à l’épreuve des stratégies de sécurité appliquées aux systèmes d’information. Des équipes suffisamment efficaces pour que, lors de l’édition 2009 des Assises de la Sécurité, l’atelier de Vupen ait fait salle comble et ait attiré l’intérêt de représentants de la grande distribution, des télécommunications ou encore de l’Armée.

Pour iOS, c’est encore Safari qui a servi de porte d’entrée. Et c’est un habitué qui s’est attelé à la tâche : Charlie Miller. Analyste Sécurité chez Independent Security Evaluators, Charlie Miller a été quatre fois distingué lors de Pwn2Own. Sur Twitter, il se décrit comme le «monsieur 0-day d’Apple», autrement dit celui qui déroule des failles inconnues jusque-là dans les logiciels de la firme à la pomme. L’une des spécialités de Miller, c’est le Fuzzing. Une approche de la recherche de vulnérabilités développée notamment par Ari Takanen, directeur technique du Codenomicon finlandais. Avec Jared DeMott et Charlie Miller, il a co-signé un ouvrage dédié au sujet, «Fuzzing, for software security testing and quality assurance», publié en 2008 par Artech House. À la fin de cet ouvrage, un cas pratique est d’ailleurs consacré à la recherche de vulnérabilités dans Quicktime Player.

Le concept de base du Fuzzing est relativement simple : il s’agit de chercher les interfaces des applications accessibles de l’extérieur et de les saturer de données corrompues - au sens où elles ne sont pas cohérentes avec ce que l’application est censée traiter - avant de voir ce qui se passe... D’une certaine façon, on peut voir là un parallèle avec la compromission de sites Web par injections SQL : dans les deux cas, le logiciel n’est pas suffisamment protégé contre les tentatives d’injection de données ne correspondant pas à ce qu’il doit attendre d’un utilisateur légitime...

L’an passé, Charlie Miller soulignait notamment qu’OS X «présente une vaste surface d’attaque regroupant composants Open Source, composants tiers fermés [dont Flash], et composants Apple fermés [Aperçu, etc.]».
Chacun de ces éléments logiciels pouvant constituer un vecteur d’attaque. Récemment, dans le cadre d’un entretien accordé au magazine allemand Heise, il explique son opiniâtreté à attaquer les logiciels d’Apple : «J’utilise différents produits Apple et il est dans mon intérêt qu’ils soient aussi sûrs que possible [...] Si vous n’écoutez qu’Apple (ou les fanboys Mac), vous croirez que les Mac sont impossibles à pirater; ce qui n’est pas le cas.»

Surtout, pour lui, s’il est important de connaître les failles pour mesurer le niveau de sûreté d’un logiciel, cela ne se résume pas à cela : «vous devez prendre en compte ceux qui vous menacent et les ressources dont ils disposent.» Du coup, pour lui aussi, à l’heure actuelle, «un Mac avec Snow Leopard est le choix le plus sûr [pour surfer sur Internet] principalement en raison de sa part de marché.» Mais l’OS des Mac est-il plus sécurisé ? Non, répond-il sans réserve : «dans mon expérience, il a été plus facile de trouver et d’exploiter des vulnérabilités dans Mac OS X que dans les systèmes Windows modernes (Vista et 7).» D’ailleurs pour lui, le navigateur Web le plus sûr est Google Chrome. Et de recommander au passage de désactiver toute extension superflue.

Des failles, oui, mais encore faut-il pouvoir les exploiter...
Mais il y a d’un côté les failles et, de l’autre, la possibilité de les exploiter. Avec Mac OX 10.5, Apple a introduit deux dispositifs pour protéger son système d’exploitation contre cela : l’ASLR et le DEP.
Le premier, ou Address Space Layout Randomization, consiste à introduire une part de hasard dans la distribution des zones de données dans la mémoire virtuelle. Et de limiter ainsi les possibilités d’exécution d’un code malicieux introduit en mémoire par dépassement de la mémoire tampon, par exemple. Le DEP vient compléter le premier dispositif en interdisant l’exécution de code injecté malgré tout dans des zones mémoires réservées à des données. Le DEP repose étroitement sur l’architecture matérielle de l’ordinateur.

Dans Mac OS X 10.5 et 10.6, l’ASLR est trop partiel. Charlie Miller souligne ainsi «qu’il y a beaucoup de choses qui ne sont pas aléatoires, comme l’emplacement du dynamic linker [qui s’occupe de chercher en mémoire et de lier les librairies partagées lorsqu’un applicatif est lancé], ou encore de la pile et du tas [deux espaces de la mémoire où sont stockées temporairement certaines données].» Et, pour le DEP, la situation n’est pas meilleure : il ne s’applique qu’aux processus 64 bits. Pour Charlie Miller, il faut rapporter cela au monde d’en face : «Dans Windows, l’ASLR est complet et ils ont le DEP.» Et si, pour Apple, le passage au 64 bits améliore la sécurité, pour Miller, «cela ne rend le contournement de DEP que plus difficile.» Mais pas impossible.

Certes, comme le souligne Charlie Miller, Apple a mis à la disposition des développeurs - et utilise dans Safari - des outils venant encore renforcer la sécurité : les «canaris.» Il s’agit de valeurs de références qui sont placées dans une mémoire tampon et permettent de vérifier les données stockées dans la pile pour surveiller d’éventuels dépassements de mémoire tampon : la première donnée corrompue dans ce cas devant être justement le canari. Mais là encore, l’expert souligne que l’utilisation de ce type de systèmes de sécurité s’appuyant sur des spécificités de compilation peut nécessiter une migration d’environnement de développement et n’est donc pas totalement adapté aux gros projets avec un fort historique.

Safari, victime de son âge ?
S’il y a bien une application à laquelle on pourrait être tenté d’appliquer cette perspective, c’est Safari. Une porte-fenêtre d’autant plus sensible qu’elle est ouverte sur un monde où l’hostilité ne manque pas. Et là, Apple a pris un retard sensible sur Google et son Chrome : ce dernier est intégralement conçu pour isoler les uns des autres les processus de rendu HTML et les extensions; c’est le concept du sandboxing, l’enfermement dans des bacs à sable, littéralement.
Safari pour Mac pourrait donner l’impression de recourir au sandboxing pour les plug-ins comme flash, mais l’isolation n’est pas complète - elle est juste là pour empêcher le composant de faire planter le navigateur. Mac OS X Lion pourrait changer quelque peu la donne : un nouveau processus est associé à Safari, et il pourrait être exclusivement dédié au rendu HTML, Safari Web Content. Mais on reste loin de Chrome qui isole chaque onglet dans un processus dédié. Et puis, pour Miller, Apple «n’a pas réussi - ou n’a pas cherché» à rendre régulièrement disponibles pour Safari les mises à jour apportées à son moteur de rendu, Webkit. Comme pour mieux illustrer cette affirmation, Chrome a déjà profité d’un correctif de la faille exploitée lors du dernier Pwn2Own pour le faire tomber.

Changement de stratégie ?
De manière globale, c’est toute l’approche de la sécurité d'Apple que Charlie Miller fustigeait ainsi début mars, même s’il lui concédait d’être «plutôt réactive aux bugs» qu’il a pu lui soumettre : «Apple ne paie pas de chercheurs en sécurité. Apple part du principe qu’il n’a pas de problème de sécurité et qu’il n’a pas besoin de travailler avec des chercheurs.» Pire, selon lui, «Apple est certainement capable de produire un produit sûr, mais n’en a juste pas encore fait l’effort.» Et, justement, Apple a peut-être changé son fusil d’épaule et lui a soumis - parmi d’autres - une pré-version de Mac OS X Lion.


En outre, Apple a récemment recruté plusieurs spécialistes de la sécurité informatique : David Rice, un ancien de la NSA, Ivan Krstic, ancien directeur de l’OLPC, ou encore Windows Snyder, qui a notamment contribué au renforcement de la sécurité de Firefox.

Et puis il a cette apparente convergence entre Mac OS X iOS. Apple utilise le sandboxing de manière étendue dans iOS, mais pas dans Mac OS X; c’est peut-être appelé à évoluer. ALSR est arrivé dans iOS avec la version 4.3; son utilisation sera peut-être étendue avec Lion. La signature du code est également mise à profit pour sécuriser iOS. Avec le Mac App Store, elle est employée pour protéger les applications distribuées par ce biais, contre le piratage.
Mais Apple prévoit peut-être d’aller plus loin...