Bartel Alexandre

Depuis ses origines et jusqu’à des mises à jour récentes des versions 8, 11 et 17, les archives Java, étaient comme une boîte de chocolats : on ne pouvait jamais savoir si on allait faire tomber la JVM… ou bien l’Android RunTime dans Android 13.

Après un article sur une confusion de type [1] et sur la sérialisation [2], il faut bien que l’on vous présente une combinaison des deux avec en bonus, un TOCTOU et des objets pas vraiment immuables dedans. Eh oui ma p’tite dame, tout cela est bien dans le CVE-2020-2805 la dernière vulnérabilité Java qui permet de s’échapper de la sandbox. Du code Java c’est comme Freddie, ça veut toujours se libérer.

Aujourd’hui, les développeurs de code malveillant sont capables de contourner les mesures de sécurité et les techniques d’analyse les plus poussées grâce à de simples mécanismes appelés « bombes logiques ». Un exemple significatif est le Google Play qui accepte toujours des applications malveillantes pouvant déjouer ses barrières de sécurité. Cette introduction aux bombes logiques permet de sensibiliser sur les différentes solutions pouvant être mises en place pour détecter ces artifices.

Dans cet article, nous présentons une vulnérabilité de la version 3.1 de Commons Collections. Cette vulnérabilité, nommée « CommonsCollections1 », permet à un attaquant l’exécution d’un code arbitraire ou Remote Code Execution (RCE). Ce travail reprend certains concepts des deux articles publiés dans les versions précédentes de MISC en 2018 et 2019 [1,2].

Les processus de sérialisation et de désérialisation Java ne manipulent que des données et non du code. Malheureusement, comme pour une chaîne ROP, il est possible de combiner des « gadgets » Java pour exécuter du code arbitraire lorsque la désérialisation s’effectue sur des données contrôlées par un attaquant. Nous présentons dans cet article une vulnérabilité de désérialisation affectant directement les libraires standards de la machine virtuelle Java.

Certaines librairies Java permettent de transformer un objet en un flux d’octets et vice-versa. Ces processus sont appelés sérialisation et déserialisation, respectivement. Ces processus ne manipulent qu’un flux d’octets qui représente des données et non du code. Nous présentons dans cet article les bases de la sérialisation en Java et nous analysons une méthode présente dans les libraires standards de la machine virtuelle Java qui ouvre la porte à une vulnérabilité de désérialisation.

Pour continuer dans la lignée des vulnérabilités Java, nous allons présenter ici une preuve de concept pour un exploit basé sur la vulnérabilité du CVE-2017-3272 qui atomise la sandbox Java. Heureusement, cette vulnérabilité n’affecte « que » 5 versions publiques de Java 8.

La vulnérabilité CVE-2015-4843 est une vulnérabilité de type dépassement d’entier qui affecte plus de cinquante versions de Java 1.6, 1.7 et 1.8. Elle permet de s’échapper de la sandbox Java pour exécuter du code arbitraire avec les droits du processus de la machine virtuelle et est donc classée en tant que vulnérabilité « critique » par Oracle.

Les deux vulnérabilités CVE-2010-0842 exploitées sous Windows en 32 bits restent-elles toujours exploitables en mode 64 bits avec ASLR ? En théorie, il est bien plus difficile, voire presque impossible de les exploiter de manière réaliste. En pratique, nous verrons que c’est toujours possible facilement.