Logo Blog perso d'Ozwald

Coincidence

Par Oz le - Sécurité
CVE-2008-5353 GIFAR

Voici une bien jolie coïncidence je trouve, bien qu'avec un peu de travail et de jugeotte j'aurai peut être été capable de le faire exprès : on peut vaguement lier un récent buzz au sujet abordé dans l'un de mes tout derniers articles, article qui ne portait pas du tout sur une faille à la mode pourtant :) ! Du coup, faute de temps, vous n'aurez pas droit sur ce billet à un jeu de mot débile pour le titre et en prime il sera un peu moins fouillé que ce que j'aurai aimé faire. Mais bon, c'est le prix à payer pour publier pendant que c'est encore dans le vent :) (ne vous inquiétez pas : je ferai un article plus détaillé plus tard !)

Gros titres - Creative Common by "christopher.woo" on Flickr

Mais de quel buzz parle-t-il ?

Je parle du buzz portant sur le CVE-2008-5353. Oui : rien de bien nouveau (le numéro de CVE ne trompe pas), et pourtant ça ne buzz que maintenant (l'explication plus tard). Ce CVE parle d'une faille dans la JRE qui permet, via un petit tour de passe-passe, de contourner la sandbox dans laquelle les applet java sont cloisonnées lorsqu'elles sont exécutées dans le contexte d'un navigateur web. Pas mal du tout quand on sait qu'une fois sorti de la sandbox l'applet java peut exécuter n'importe quelle commande système avec les droits de l'utilisateur qui fait tourner le navigateur web. Par exemple en surfant simplement sur une page "lambda", si vous avez accepté les applet java (ce qui est par exemple le cas par défaut dans Safari sur MacOSX...) l'applet peut, à votre insu, télécharger un fichier, l'enregistrer dans un coin sur le disque dur, lui donner les droits d'exécution, et enfin s'arranger pour qu'il soit exécuté à chaque ouverture de session (si jamais ça vous rappelle quelque chose, c'est que vous n'êtes pas stupide ;) )

Backdoor - Creative Common by "Anders Ljungberg" on Flickr

Parlons technique !

Comment, techniquement, celà se fait-il ? Et bien c'est sur cette partie que j'aurai aimé pouvoir passer plus de temps parce que n'étant pas un expert de Java j'ai un peu de mal à saisir rapidement toutes les subtilités du chmilblick. Enfin je tente tout de même de vous relater ce que j'ai saisi, et je ferai un article plus détaillé quand j'aurai eu le temps de bien comprendre.

En substance Java permet la sérialisation d'objets et c'est là dedans qu'on va aller fouiller. En effet la dé-sérialisation de l'objet de type "sun.util.calendar.ZoneInfo" est, semble-t-il pour des raisons historiques, gérée dans un bloc à privilèges élevés (i.e. il s'affranchit des restrictions de type sandbox). Jetons un oeil au code de désérialisation des objets de type "sun.util.calendar" pour bien comprendre :

private void readObject(ObjectInputStream input) throws IOException, ClassNotFoundException 
{
   ...
   ZoneInfo zoneinfo = (ZoneInfo)AccessController.doPrivileged(new PrivilegedExceptionAction() {
           public Object run() throws Exception
           {
               return input.readObject();
           }
   });
   if (zi != null) {
          zone=zi;
   }
...
}

Donc, comment exploiter ça ? L'idée c'est de demander la désérialisation d'un objet qui soit reconnu comme de classe "sun.util.calendar", nous démmerder pour que la désérialisation de l'objet "sun.util.calendar.ZoneInfo" soit en réalité la désérialisation d'un tout autre type d'objet, et que la méthode "readObject" de ce prétendue "sun.util.calendar.ZoneInfo" permettent de faire des choses ''sympa'' que la sandbox nous interdirait :) !

Dans cet article très complet l'auteur explique qu'il remplace son objet de type zoneinfo par un objet de type ClassLoader, et qu'il en surcharge la méthode "readObject" pour attribuer "this" (i.e. son objet ClassLoader) à une variable statique afin qu'il ne soit pas garbage-collecté. En effet son objet ClassLoader devrait être garbage collecté à la fin de la tentative de désérialisation en ZoneInfo puisqu'on voit bien dans l'extrait de code que je vous ai mis que l'objet retourné n'est pas attribué à la variable "zone" si il n'est pas classe ZoneInfo valide (et du coup il ne se retrouve référencé par rien, d'où le coup de garbage collector)

Bon, ça c'est l'idée du principe de base, et nous allons devoir (hélas) nous en contenter pour l'instant parce que je n'ai pas eu le temps de creuser plus que ça :( Mais, tant pis si je me répètes : je pondrai un autre article plus détaillé dès que j'aurai eu le temps de jouer un petit peu avec tout ça (ça tombe bien, c'est un weekend de 3 jours qui s'annonce ;) ...)

Echaffaudage - Creative Common par "aleske" sur Flickr

Pourquoi ça ne buzz que maintenant ?

Easy as a pie : Comme je l'ai dit en tout début d'article ce bug est vieux1 néanmoins les applets java sont toujours autorisés par défaut sur le navigateur par défaut de MacOSX (safari) et.....et....et....et la dernière JRE Apple n'est toujours pas patché :) ! Du coup quelques chercheurs ont commencé à faire du boucan et ça suffit à faire monter un petit buzz (on le comprend aisément n'empèche...si on résume : les utilisateurs de MacOSX sont par défaut vulnérables à de l'exécution de code à distance plus de 6 mois après que la faille ait pourtant été patché sur les JRE SUN :( )

C'est quoi le rapport avec l'un de mes articles précédents ?

J'avoue que c'est un peu capilotracté mais moi en tout cas j'y ai pensé tout de suite : Vous pondez une applet qui exploite cette faille, vous en faite un GIFAR, vous uploadez ce GIFAR n'importe où sur internet (simplissime vu le nombre de forum au monde qui permettent de s'inscrire en deux secondes et d'uploader un avatar), ensuite il ne vous reste qu'à trouver un XSS sur un site quelconque pour y insérer votre applet et vous ownez tout les MacOSX qui passent :) Flipant hein ? Boah...au moins ça me permet de taquiner mes amis qui sont sous Mac et qui croient encore que OSX est "imprenable" :D !

  1. Il a même été utilisé dans le dernier Pwn2own...on fait mieux dans le genre "underground discret"