IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    6 093
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 6 093
    Points : 148 567
    Points
    148 567
    Par défaut La bibliothèque Java Apache Commons Collection a une vulnérabilité RCE
    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Futur Membre du Club
    Homme Profil pro
    Développeur décisionnel
    Inscrit en
    février 2014
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : Maroc

    Informations professionnelles :
    Activité : Développeur décisionnel

    Informations forums :
    Inscription : février 2014
    Messages : 16
    Points : 7
    Points
    7
    Par défaut
    marshalling et unmarshalling, non marshmalling et unmarshmalling

  3. #3
    MikeRowSoft
    Invité(e)
    Par défaut
    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.

  4. #4
    Membre éprouvé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2007
    Messages
    697
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Calvados (Basse Normandie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : janvier 2007
    Messages : 697
    Points : 1 237
    Points
    1 237
    Par défaut
    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.

  5. #5
    MikeRowSoft
    Invité(e)
    Par défaut
    Citation Envoyé par atha2 Voir le message
    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.

  6. #6
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    7 183
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 7 183
    Points : 9 306
    Points
    9 306
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par atha2 Voir le message
    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 ?
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  7. #7
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    7 183
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 7 183
    Points : 9 306
    Points
    9 306
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Logicielz Voir le message
    marshalling et unmarshalling, non marshmalling et unmarshmalling
    Stéphane est un fan de marshmallow, c'est sûr
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  8. #8
    Membre confirmé Avatar de heid
    Profil pro
    Inscrit en
    mai 2002
    Messages
    388
    Détails du profil
    Informations personnelles :
    Localisation : France, Indre et Loire (Centre)

    Informations forums :
    Inscription : mai 2002
    Messages : 388
    Points : 587
    Points
    587
    Par défaut
    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.

  9. #9
    syj
    syj est déconnecté
    Membre régulier

    Profil pro
    DEV
    Inscrit en
    septembre 2002
    Messages
    38
    Détails du profil
    Informations personnelles :
    Localisation : France, Seine Maritime (Haute Normandie)

    Informations professionnelles :
    Activité : DEV

    Informations forums :
    Inscription : septembre 2002
    Messages : 38
    Points : 108
    Points
    108
    Par défaut
    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

  10. #10
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 300
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 300
    Points : 3 581
    Points
    3 581
    Billets dans le blog
    12
    Par défaut
    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.
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  11. #11
    Modérateur

    Profil pro
    Inscrit en
    septembre 2004
    Messages
    12 249
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2004
    Messages : 12 249
    Points : 20 727
    Points
    20 727
    Par défaut
    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.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  12. #12
    syj
    syj est déconnecté
    Membre régulier

    Profil pro
    DEV
    Inscrit en
    septembre 2002
    Messages
    38
    Détails du profil
    Informations personnelles :
    Localisation : France, Seine Maritime (Haute Normandie)

    Informations professionnelles :
    Activité : DEV

    Informations forums :
    Inscription : septembre 2002
    Messages : 38
    Points : 108
    Points
    108
    Par défaut
    @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);
        } 
     
    }

  13. #13
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    7 183
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 7 183
    Points : 9 306
    Points
    9 306
    Billets dans le blog
    1
    Par défaut
    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
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  14. #14
    Membre habitué
    Homme Profil pro
    Développeur Java
    Inscrit en
    décembre 2012
    Messages
    31
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2012
    Messages : 31
    Points : 151
    Points
    151
    Par défaut
    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.

  15. #15
    Membre chevronné
    Inscrit en
    mai 2006
    Messages
    1 364
    Détails du profil
    Informations forums :
    Inscription : mai 2006
    Messages : 1 364
    Points : 1 984
    Points
    1 984
    Par défaut
    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...

  16. #16
    Modérateur

    Profil pro
    Inscrit en
    septembre 2004
    Messages
    12 249
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2004
    Messages : 12 249
    Points : 20 727
    Points
    20 727
    Par défaut
    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...

    Citation Envoyé par hwoarang Voir le message
    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.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  17. #17
    Membre chevronné
    Inscrit en
    mai 2006
    Messages
    1 364
    Détails du profil
    Informations forums :
    Inscription : mai 2006
    Messages : 1 364
    Points : 1 984
    Points
    1 984
    Par défaut
    Citation Envoyé par thelvin Voir le message
    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).

  18. #18
    Modérateur

    Profil pro
    Inscrit en
    septembre 2004
    Messages
    12 249
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2004
    Messages : 12 249
    Points : 20 727
    Points
    20 727
    Par défaut
    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.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  19. #19
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    7 183
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 7 183
    Points : 9 306
    Points
    9 306
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par thelvin Voir le message
    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
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  20. #20
    Membre chevronné
    Inscrit en
    mai 2006
    Messages
    1 364
    Détails du profil
    Informations forums :
    Inscription : mai 2006
    Messages : 1 364
    Points : 1 984
    Points
    1 984
    Par défaut
    Citation Envoyé par thelvin Voir le message
    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).

    Citation Envoyé par thelvin Voir le message
    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.


    Citation Envoyé par OButterlin Voir le message
    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

Discussions similaires

  1. Réponses: 4
    Dernier message: 21/02/2007, 12h13
  2. commons validator : valider une collection
    Par delas dans le forum Struts 1
    Réponses: 1
    Dernier message: 20/02/2007, 13h15
  3. Passage d'une collection depuis une Appli java
    Par Florent Coulon dans le forum iReport
    Réponses: 2
    Dernier message: 09/11/2006, 11h30
  4. [DisplayTag] java.lang.NoClassDefFoundError: org/apache/commons/lang/UnhandledException
    Par MAJIK_ENIS dans le forum Taglibs
    Réponses: 18
    Dernier message: 06/04/2006, 10h18

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo