Discussion :

[Stéphane le calme]

Un chercheur en sécurité donne des détails sur la vulnérabilité RCE
qui affecte la bibliothèque Java Apache Commons Collection

Steve Breen, un chercheur en sécurité travaillant pour le compte de Foxglove Security, s’est exprimé au sujet d’une faille dans la bibliothèque Apache Commons due à une méthode grâce à laquelle Java désérialise les objets et l’utilise pour exploiter les installations JBoss, WebSphere et WebLogic.

Il commence par rappeler que la plupart des langages fournissent des méthodes/fonctions aux utilisateurs afin qu’ils puissent exporter les données des applications sur le disque ou en faire un flux sur le réseau. C’est le processus de conversion de ces données application dans un autre format plus convenable pour le transport qui est appelé sérialisation (ou linéarisation ou marshalling). L’action d’appliquer le procédé inverse afin d’en récupérer la variable d’origine s’appelle la désérialisation (ou délinéarisation ou unmarshalling).

« Les vulnérabilités surviennent lorsque les développeurs écrivent du code qui accepte des données sérialisées des utilisateurs et tentent de les désérialiser pour les utiliser dans un programme. En fonction du langage, cela peut conduire à toutes sortes de conséquences », a-t-il expliqué, prenant le soin de préciser que la conséquence la plus intéressante selon lui est l’exécution du code à distance. Raison pour laquelle, il a décidé d’étendre le sujet en se focalisant dessus.

Il rappelle que les vulnérabilités dans la désérialisation sont tributaires du langage et explique qu’une seule de ces vulnérabilités dans les bibliothèques que votre application charge, y compris celles qu'elle n’utilise pas, peut avoir des répercussions. Il illustre ses propos par un exemple de code Java basique sur la façon dont quelqu’un pourrait utiliser la sérialisation.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
import java.io.ObjectInputStream;
import java.io.FileInputStream;
import java.io.ObjectOutputStream;
import java.io.FileOutputStream;
 
public class SerializeTest{
    public static void main(String args[]) throws Exception{
        //Voici l’objet que nous allons sérialiser.
        String name = "bob";
 
        //Ecrit la donnée sérialisée dans le fichier "name.ser"
        FileOutputStream fos = new FileOutputStream("name.ser");
        ObjectOutputStream os = new ObjectOutputStream(fos);
        os.writeObject(name);
        os.close();
 
        // Lit la donnée sérialisée depuis le fichier "name.ser"
        FileInputStream fis = new FileInputStream("name.ser");
        ObjectInputStream ois = new ObjectInputStream(fis);
 
        //Lit l’objet depuis le flux de données et le convertit à nouveau en chaîne de caractère
       String nameFromDisk = (String)ois.readObject();
 
        //Affiche le résultat.
        System.out.println(nameFromDisk);
        ois.close();
    }
}

Ce que ce code fait c’est simplement d’écrire la chaîne de caractères « bob » dans le disque, puis le lit et affiche le résultat. Voici les résultats obtenus lorsque ce code est exécuté.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
breens@us-l-breens:~/Desktop/SerialTest$ java SerializeTest
bob
breens@us-l-breens:~/Desktop/SerialTest$ xxd name.ser
0000000: aced 0005 7400 0362 6f62 ....t..bob

Il faut préciser que le fichier name.ser sur le disque est binaire, « il a quelques caractères non imprimables, en particulier l’octet ‘aced 005’ ».

Maintenant, rajoutons une classe pour personnaliser la sérialisation des objets.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
import java.io.ObjectInputStream;
import java.io.FileInputStream;
import java.io.ObjectOutputStream;
import java.io.FileOutputStream;
import java.io.Serializable;
import java.io.IOException;
 
public class SerializeTest{
 
    public static void main(String args[]) throws Exception{
        //This is the object we're going to serialize.
        MyObject myObj = new MyObject();
        myObj.name = "bob";
 
        //Ecrit la donnée sérialisée dans le fichier "object.ser"
        FileOutputStream fos = new FileOutputStream("object.ser");
        ObjectOutputStream os = new ObjectOutputStream(fos);
        os.writeObject(myObj);
        os.close();
 
        //Lit la donnée sérialisée depuis le fichier "object.ser"
        FileInputStream fis = new FileInputStream("object.ser");
        ObjectInputStream ois = new ObjectInputStream(fis);
 
        //Lit l’objet depuis le flux de données et le convertit en chaîne de caractères
        MyObject objectFromDisk = (MyObject)ois.readObject();
 
        //Print the result.
        System.out.println(objectFromDisk.name);
        ois.close();
    }
}
 
class MyObject implements Serializable{
    public String name;
    private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException{
        in.defaultReadObject();
        this.name = this.name+"!";
    }
}

Voici le résultat qui s’affiche lorsqu’on l’exécute.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
breens@us-l-breens:~/Desktop/SerialTest$ java SerializeTest
bob!
breens@us-l-breens:~/Desktop/SerialTest$ xxd object.ser
0000000: aced 0005 7372 0008 4d79 4f62 6a65 6374 ....sr..MyObject
0000010: cf7a 75c5 5dba f698 0200 014c 0004 6e61 .zu.]......L..na
0000020: 6d65 7400 124c 6a61 7661 2f6c 616e 672f met..Ljava/lang/
0000030: 5374 7269 6e67 3b78 7074 0003 626f 62 String;xpt..bob

En regardant le résultat, au lieu de voir s’afficher « bob » comme défini en entrée, c’est plutôt « bob! » qui est imprimé. Pour le comprendre, « la clé ici est la méthode readObject bien entendu. Lorsque Java lit un objet sérialisé, la première chose qu’il fait après avoir lu des octets raw, c’est d’appeler la méthode définie par l’utilisateur ‘readObject’ si elle existe. Dans ce cas, la méthode ‘readObject’ ajoute un point d’exclamation au nom » explique Breen. « Et si au lieu d’ajouter un point d’exclamation à une chaîne de caractères définie par l’utilisateur, elle était utilisée pour exécuter une commande définie par l’utilisateur sur le système d’exploitation ? »

Il explique que cette vulnérabilité avait déjà été présentée le 28 janvier de cette année à l’AppSecCali par Gabriel Lawrence et Chris Frohoff. Il y a neuf mois, pendant leur speech, Gabriel et Chris se sont servis d’une vulnérabilité lors de la désérialisation dans la bibliothèque Common Collections, « une bibliothèque qui s’avère EXTRÊMEMENT populaire dans le monde Java », précise Breen.

« Ce que cela signifie c’est que toute application ou framework d’application qui l’utilise (et il y en a beaucoup) et désérialise des données non fiables (il y en a aussi beaucoup) est désormais sujet d’une vulnérabilité CVSS 10.0 ». Cela implique que toute personne sur votre réseau et potentiellement sur internet peut compromettre plusieurs de vos applications serveur, mais également que cette vulnérabilité s’exécute dans la mémoire.

« Chaque application serveur vient avec son propre ensemble de bibliothèques. Pire encore, chaque application que vous déployez sur le serveur vient souvent avec son propre ensemble également », a déclaré Breen. « Pour résoudre complètement ce problème, vous avez besoin de trouver et de mettre à jour chacune de ces bibliothèques individuellement ».

Se basant sur la façon dont Java exécute le code défini par l'utilisateur lors de la désérialisation des objets, Breen a expliqué qu’il était possible de personnaliser des charges utiles pour obtenir un accès shell sur les machines où sont exécutés WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, et toute machine qui utilise Java Remote Method Invocation.

Quand il rédigeait son billet, Breen a déclaré que tous les produits mentionnés étaient vulnérables. Il faut noter qu’entretemps Apache et Jenkins sont en train de travailler sur un patch à apporter à leur code. Jenkins a proposé une solution de contournement qui désactive le système Jenkins CLI utilisé pour l’attaque, un correctif devrait être publié mercredi.

« Malheureusement, la vulnérabilité ne nous a pas été révélée avant sa publication, alors nous travaillons toujours sur un correctif plus efficace », a expliqué l'équipe Jenkins. Même son de cloche chez OpenNMS dont le PDG Jeff Gehlbach a avancé sur Twitter que Breen aurait dû notifier les projets affectés par la vulnérabilité zéro-day avant la publication du billet. En retour, Breen a avancé qu’il ne la considérait pas comme étant une vulnérabilité zéro-day.

De son côté, Apache Commons a proposé un correctif dans la branche 3.2.X qui apporte un drapeau pour désactiver la sérialisation sur la classe vulnérable InvokerTransformer par défaut. « Utiliser la nouvelle version de la bibliothèque signifie que toute tentative de désérialiser une InvokerTransformer va entraîner une exception », a expliqué le développeur Thomas Neidhart, de l’équipe Apache Commons.


Source : blog FoxGlove Security, Jenkins, twitter JeffGehlbach, patch InvokerTransformer

[Logicielz]

marshalling et unmarshalling, non marshmalling et unmarshmalling

[MikeRowSoft]

Malheureusement, il faut encore déplorer le fait que si un code d'évaluation de clé de produit est fourni en binaire dans ISO et autres fichiers à "l'utilisateur" final, ben que sa arrange pas les affaires, surtout quand le reverse engineering de pro est une science infuse... Mais la plus part des keygens étant algorithmique, il y a des limites qui n'ont pas été franchis.

Désolé du hors sujet mais c'était plus fort que moi.

[atha2]

Il y a sûrement un truc qui m'échappe mais exécuter un fichier object lu dans la méthode readObject, sans valider son contenu et son origine, me semble aussi débile (plus en faite vu que normalement readObject ne sert pas à ça) que faire une requête SQL non préparée sans valider le formulaire uploadé par un utilisateur.

[MikeRowSoft]

Il y a sûrement un truc qui m'échappe mais exécuter un fichier object lu dans la méthode readObject, sans valider son contenu et son origine, me semble aussi débile (plus en faite vu que normalement readObject ne sert pas à ça) que faire une requête SQL non préparée sans valider le formulaire uploadé par un utilisateur.

Pense copyright.
Normalement il y a au minimum deux couches de vernis pour en être propriétaire.
Mais comme très souvent modifiable par groupe root, administrator et autres.

[OButterlin]

Il y a sûrement un truc qui m'échappe mais exécuter un fichier object lu dans la méthode readObject, sans valider son contenu et son origine, me semble aussi débile (plus en faite vu que normalement readObject ne sert pas à ça) que faire une requête SQL non préparée sans valider le formulaire uploadé par un utilisateur.

Que veux-tu dire ?

La désérialisation n'a pas à se poser la question de ce que fait l'objet qu'elle va créer, comment le pourrait-elle ?

[OButterlin]

marshalling et unmarshalling, non marshmalling et unmarshmalling

Stéphane est un fan de marshmallow, c'est sûr

[heid]

J'ai été voir sur la mailing list les mec d'apache ont été au courant après moi ...

Comment tu peux sérieusement écrire un article sans prévenir les mains commiteurs quelque jours avant histoire que le fix soit dispo le jour de la publication. C'est pas sérieux comme comportement. Même si l'exploit existe depuis longtemps il devait se douter que ça allait faire du bruit.

[syj]

Je trouve que l'article n'est pas clair. Le problème ne vient pas seulement du readObject !
Quand vous déserialisez du code, il ne charge pas "des classes" en mémoire. Il charge juste des attributs. Le code n'est pas embarqué dans la sérialisation.

Le problème vient d'une classe comme InvokerTransformer
http://svn.apache.org/repos/asf/comm...ansformer.java

A partir de cette classe, vous pouvez appeler la méthode d'une classe avec les paramètres que vous vous voulez.

Alors, si vous trouvez un objet qui a dans son readObject, la possibilité d'appeler d'une Instance de InvokerTransformer que vous avez préparré pour éxecuter la méthode que vous souhaitez avec les paramètres de votre de choix.

Mais, il y a moyen d'avoir l'éxecution de votre InvokerTransformer par d'autre moyen que le readObject. Le readObject est juste un moyen , mais ce n'est pas l'unique moyen d'exploiter une classe comme InvokerTransformer

[Gugelhupf]

Bonjour @syj,
Le protocole de sérialisation contient les métadonnées (les types des attributs) ainsi que des valeurs.
Je n'ai pas cherché en détail la source du problème mais le 2ème exemple montre que le problème vient forcément de "Java", donc :

• Soit du protocole de sérialisation (writeObject)
• Soit du protocole de désérialisation (readObject)
• Soit du protocole lui-même (c'est-à-dire la manière dont les métadonnées et valeurs sont structurés)

InvokerTransformer n'est au final qu'un wrapper qui utilise des classes de base.

EDIT 13/11/2015: Lorsque j'ai dit que le "problème" venait forcément de Java en citant le 2ème exemple comme référence, c'est que ce dernier ne contient que tu code Java, pas Apache, j'aurais du chercher en détail la source du problème avant de répondre mais comme moi voisin ci-dessous l'a dit : le "problème" évoqué est lié au fait qu'on puisse redéfinir une méthode magique readObject de la classe qu'on désérialise. C'est une notion de la sérialisation Java qu'on utilise peu mais qui existe.

[thelvin]

Disons que le problème vient du fait qu'il soit possible d'ajouter un comportement lors d'une désérialisation : la désérialisation est pensée comme ne faisant que lire des données et les mettre dans un objet en mémoire. Pas faire des choses annexes.

Mais, dans un langage objet, c'est censé aller de soi, tout comme on a besoin d'un constructeur pour s'assurer de mettre l'objet dans un état initialisé cohérent avant de pouvoir s'en servir.
Du coup, ce n'est pas tellement évitable tout en restant dans le principe objet.

La raison pour laquelle ça pose problème dans la désérialisation mais pas dans un constructeur, c'est qu'on ne sait pas ce qu'il y a dans les données qu'on s'apprête à désérialiser. Cela peut venir de n'importe où et contenir n'importe quoi. Et ça, c'est vraiment pas OK du tout, tant en termes de sécurité que de stabilité.
Le programmeur sait quels objets il va chercher à utiliser une fois que la désérialisation sera faite. Il ne devrait pas avoir à se méfier de ce qui se passe si ce ne sont en fait pas ces objets-là. Ça devrait être "quelque chose comme un ClassCastException" et puis c'est tout. Il faudrait que la désérialisation sache quels objets elle est censée fournir, et fasse une erreur si elle tombe sur autre chose.
Sur le principe ce "ça devrait" est bien joli, mais ce n'est pas évident à définir dès que les objets sont des conteneurs génériques d'autres objets. Quoi qu'il en soit, pour la sérialisation Java c'est trop tard : elle ne le fait pas et c'est tout. La seule vraie solution serait de ne pas l'utiliser.

Dans la même vaine, on peut s'inspirer de ce qui se passe quand on fait de la sérialisation en Java, mais pas avec la sérialisation native Java. XML, JSON, Protocol Buffers ou autres trucs maison. Ceux-là désérialisent bel et bien en sachant a priori quel objet doit être produit. Si le programmeur s'amuse à désérialiser des objets qui ont un comportement et qui viennent d'une ressource peu fiable, on n'y peut plus grand-chose.

[syj]

@Gugelhupf
Tu est surrement d'accord avec ce cas ?

Le pirate sérialise un objet avec un attribut name="toto" dans objet.ser avec la classe:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
class MyObject implements Serializable{
    public String name;
    private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException{
        in.defaultReadObject();
        this.name = this.name + "!";
    }
}

L'utilisateur récupère "objet.ser", puis il le déserialise avec le code suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
class MyObject implements Serializable{
    public String name;
    private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException{
        in.defaultReadObject();
        this.name = this.name;
    }
}

L'utilisateur aura dans son attribut name="toto" et non "toto!".



C'est pourquoi , un meilleur exemple aurait été un code de ce type:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
class MyObject implements Serializable{
    public Transformer init;
    public Object o;
 
    private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException{
        in.defaultReadObject();
	init.transform(o);
    }
}

Le pirate crée objet.ser avec un MyObject avec :
- o = new File("un fichier a ne pas supprimé")
- init = InvokerTransformer.getInstance("delete");


Lorsque l'utilisateur désarialisera le objet.ser du pirate, il éxecutera la commande que le pirate a préparré.


Après , un objet de ce type serait aussi problèmatique si onEvent est systématiquement appellé par le programme chargeant l'objet.ser.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
class Plugin implements Serializable{
    public Transformer init;
    public Object o;
 
    private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException{
        in.defaultReadObject();	
    }
 
    public onEvent() {
	init.transform(o);
    } 
 
}

[OButterlin]

Pour sérialiser, c'est writeObject qui est utilisé, pas readObject.

Ensuite, le fichier .ser contient la valeur des attributs de l'objet mais pas la classe elle même.
L'application utilisatrice garde sa définition de classe et n'est pas impactée le mécanisme de désérialisation.
Finalement, je ne vois pas trop où est le problème

[amine.hirri]

Si j'ai bien compris, pour réaliser une attaque moyennant cette faille, il faut avoir la main sur le serveur hébergeant le code Java pour modifier le fichier contenant l'objet serialisé!
Dans ce cas on ne peut pas parler d'une prise de contrôle à distance sans avoir déjà infecté la machine physique.

[hwoarang]

D'après ce que je comprends de la faille, il semble que l'objet vulnérable est InvokerTransformer (d'ailleurs, le patch pour l'instant consiste à la désactiver).
Cette fonction contient une classe et une methode à appeler par reflexion. De ce point de vue la, effectivement, ca permet d'executer du code arbitraire. Mais bon, j'ai quand meme un peu de mal à croire qu'on déserialize une classe de ce type depuis une source inconnue/non fiable.
Ceci dit, c'est peu etre ce que fait le framework quand meme...

[thelvin]

Non vous ne comprenez pas.

Il existe dans l'écosystème Java, des classes sérialisables très courantes, et ces classes font une action à la désérialisation. Cette action est programmable de part les propriétés de l'objet désérialisé lui-même.
Et, hum, c'est en effet complètement dingue, mais c'est le cas.

Ça signifie que chaque fois qu'on reçoit quelque chose à désérialiser, cette chose peut possiblement contenir un objet de cette classe, configuré pour tout foutre par terre ou donner les accès root. Si donc on est en train de désérialiser un objet qui vient d'une source peu sûre, ça fait un gros danger.
Et il existe des plate-formes qui désérialisent carrément des cookies venant du navigateur...

Ceci dit, c'est peu etre ce que fait le framework quand meme...

Le problème c'est qu'on ne choisit pas quelles classes on désérialise. On ne choisit que quelles sources on désérialise. Et encore, pas tant que ça si on utilise une plate-forme qui gère des trucs à notre place.

[hwoarang]

Il existe dans l'écosystème Java, des classes sérialisables très courantes, et ces classes font une action à la désérialisation. Cette action est programmable de part les propriétés de l'objet désérialisé lui-même.

Tu es sur de ca ? Ca parait enorme quand meme. D'ailleurs, dans le cas présent, le probleme semble s'orienter sur une classe particuliere (alors que si je te suis, ce serait toutes les classes serializables qui seraient vulnérables).

[thelvin]

Non non, quand je dis "des" je veux dire plus d'une. Mais il y en a une en particulier qui est sous le feu des projecteurs.
C'est pas non plus des centaines, mais vu que celle dont on parle est pratiquement dans tous les projets, ça change pas grand-chose.

[OButterlin]

Il existe dans l'écosystème Java, des classes sérialisables très courantes, et ces classes font une action à la désérialisation. Cette action est programmable de part les propriétés de l'objet désérialisé lui-même.

Si je te suis bien, il existe des classes qui font une action programmable par réflexion en fonction de valeur de propriété de la classe désérialisée, c'est bien ça ?
Là je trouve que ce n'est plus le problème de la désérialisation mais de la classe elle même, il ne faut pas jeter le mécanisme sous prétexte qu'on code n'importe quoi

[hwoarang]

Non non, quand je dis "des" je veux dire plus d'une. Mais il y en a une en particulier qui est sous le feu des projecteurs.

Ok. Effectivement, j'avais lu un peu vite et compris que tu parlais de toutes les classes déserialisées (autrement dit, une bidouille de la JVM).

C'est pas non plus des centaines, mais vu que celle dont on parle est pratiquement dans tous les projets, ça change pas grand-chose.

Bah quand meme. Ca veut dire que l'origine du probleme est chez apache, pas dans la JVM ou les API de base.

Si je te suis bien, il existe des classes qui font une action programmable par réflexion en fonction de valeur de propriété de la classe désérialisée, c'est bien ça ?
Là je trouve que ce n'est plus le problème de la désérialisation mais de la classe elle même, il ne faut pas jeter le mécanisme sous prétexte qu'on code n'importe quoi

Regardes le lien de la classe InvokerTransformer (donné dans ce thread). C'est bien ce qu'elle fait...
Sur le principe, ca me choque pas qu'elle fasse ca (quoi que). Par contre, faut faire super attention à bien valider d'ou viennent les données. J'imagine qu'on atteint les limites de la généricité. La, faut reconnaitre que c'est difficile d'aller plus loin