Journal Java ça pue c'est trop libre.

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
45
28
août
2012

Finalement j'ai l'impression que c'était inéluctable, que ça devait arriver un jour ou l'autre…

public void init()
{
   try
      {
       disableSecurity();

Alors là évidemment quand ça commence comme ça…

Bon, pour ceusses qui l'ignorent encore ou ont toujours leur plugin Java d'activé dans leur navigateur, il y a un 0Day qui circule depuis au moins 2 jours:
http://labs.alienvault.com/labs/index.php/2012/new-java-0day-exploited-in-the-wild/
http://eromang.zataz.com/2012/08/27/java-7-applet-rce-0day-gondvv-cve-2012-4681-metasploit-demo/

A priori Linux serait également impacté, mais je n'ai pas pu le vérifier : je n'ai pas le JRE d'Oracle et pas non plus l'envie de tester.
Les classes se nomment (nommaient ?) Gondzz et Gondvv. Mais Oracle n'a pas l'air inquiet pour autant.
Il y a pourtant eu un CVE très explicite d'attribué par MITRE avant celui de Kurt Seifried (RedHat):
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4681

Bien évidemment, il y a déjà un module Metasploit de disponible pour tous les script-kiddies qui ne sont pas en vacances scolaires.

Bref, en attendant la sortie de Unbreakable Java, il vous est recommandé au minimum de désactiver vos plugins dans les navigateurs ou de vous passer de la JRE d'Oracle.

NdM : cela concerne le JRE 7 et non Java 6, voir http://immunityproducts.blogspot.fr/2012/08/java-0day-analysis-cve-2012-4681.html pour une doc' (merci à René Quirion et Christophe Turbout pour leurs commentaires).

  • # Un 0-day de 2 jours?

    Posté par  . Évalué à 9.

    Un 0-day de 2 jours? C'est un 2-days alors?

    Ceci dit, tu donnes juste le nom de la fonction, qui aurait pu s'appeler plop();
    Il faudrait aller lire les 10 lignes de code de cette fonction, qui, si je comprends bien, crée un nouveau contexte de sécurité, lui donne tous les droits (entre autre sur file://) et après va exécuter du code dans ce contexte (?!?!) sans que java ou sa sandbox ne trouve rien à redire là-dessus.

    Genre, je ne suis que simple user, et je demande à mettre un bit s sur un binaire root, et que le noyau dise: ouais, vazy mon gars, tu peux le faire.

    • [^] # Re: Un 0-day de 2 jours?

      Posté par  (site web personnel) . Évalué à 5.

      lui donne tous les droits (entre autre sur file://)

      file:// c'est juste une url valide pour mettre la provenance du code executable associé au domaine de sécurité, à mon avis n'importe quel url valide fait l'affaire.

      La faille semble plutôt être que la classe "sun.awt.SunToolkit" possède une méthode getField (large et pas seulement limitée à elle-même, ie: renvoi un field de n'importe quel classe) accessible sur laquelle aucune vérification du callstack n'est faite.

      • [^] # Re: Un 0-day de 2 jours?

        Posté par  . Évalué à 2.

        file:// c'est juste une url valide pour mettre la provenance du code executable associé au domaine de sécurité, à mon avis n'importe quel url valide fait l'affaire.

        Tout à fait.

        La faille semble plutôt être que la classe "sun.awt.SunToolkit" possède une méthode getField (large et pas seulement limitée à elle-même, ie: renvoi un field de n'importe quel classe) accessible sur laquelle aucune vérification du callstack n'est faite.

        Non il semble y avoir deux failles:
        - JavaBeans peut charger sun.awt.* ce qui n'était pas possible sur Java 6 et ne devrait pas être possible sous Java 7 non plus :-)
        - La propriété "acc" qui contient le contexte sécurité d'un object "Statement"peut être modifiée par un package privilégié (comme sun.awt.SunToolkit). Ce n'était pas possible non plus avec Java 6.

        La vulnérabilité n'est pas dans la méthode getField(). L'exploit l'utilise juste pour accéder à la propriété "acc".

        • [^] # Re: Un 0-day de 2 jours?

          Posté par  (site web personnel) . Évalué à 2.

          JavaBeans n'est qu'une spec qui garantit une uniformité d'accès aux propriétés d'un objet (utile notamment pour la réflexion), que veux-tu dire ?

          • [^] # Re: Un 0-day de 2 jours?

            Posté par  . Évalué à 1.

            Il est possible de charger n'importe quel package de sun.awt.* via java.beans.Expression.

            • [^] # Re: Un 0-day de 2 jours?

              Posté par  (site web personnel) . Évalué à 2.

              Ah, au temps pour moi ; pour l'appel de méthode par réflexion (ce qui est déjà pourri) je passais par java.lang.reflect.Method :)

              • [^] # Re: Un 0-day de 2 jours?

                Posté par  . Évalué à 2.

                Enfin pour être précis, sun.awt.SunToolkit est chargé via forName() de java.lang.Class. Mais passer par Expression() de beans permet de contourner la sécurité. Je ne connais pas suffisamment Java pour savoir pourquoi.

                Dans le code de l'exploit:

                Expression localExpression = new Expression(Class.class, "forName", arrayOfObject);

                • [^] # Re: Un 0-day de 2 jours?

                  Posté par  (Mastodon) . Évalué à 5.

                  Mais passer par Expression() de beans permet de contourner la sécurité. Je ne connais pas suffisamment Java pour savoir pourquoi.

                  Le système de sécurité de Java se base sur l'analyse de la pile d'appels de méthodes. En gros, pour savoir si une opération est permise, on vérifie que chaque méthode dans la pile a bien le droit de l'appeler.

                  Comme ce système seul serait insuffisant, il y a un moyen de faire des appels de méthodes dits "privilégiés". Dans ce cas, la vérification va s'arrêter à l'endroit où l'appel privilégié est fait, sans tenir compte des permissions de l'appelant (très approximativement, on peut voir ça un peu comme le bit SetUID ou SetGID sur les permissions Unix)

                  Apparemment, le problème qu'on a ici, c'est qu'on a un de ces appels privilégiés dans la classe Expression du package Java Beans. Les classes de base du JDK s'exécutant avec un niveau de privilège très élevé (normalement, c'est sans restriction), ça permet donc, combiné avec la méthode dans AWT, d'effectuer des appels qui désactivent complètement la sécurité.

        • [^] # Re: Un 0-day de 2 jours?

          Posté par  (site web personnel) . Évalué à 2. 

          Oracle Java 1.7 provides an execute() method for Expression objects, which can use reflection to bypass restrictions to the sun.awt.SunToolkit getField() function, which operates inside of a doPrivileged block. The getField() function also uses the reflection method setAccessible() to make the field accessible, even if it were protected or private. Because sun.awt.SunToolkit is public, it can be called from anywhere.

          Donc c'est la combinaison d'un bug dans Expression + le setAccessible de getField dans sun.awt.SunToolkit (qui est éxécuté sous le domaine de sécurité de Expression et non de l'applet) qui permet ce bug.

          C'est quand même énorme d'avoir laissé passer ça.

    • [^] # Re: Un 0-day de 2 jours?

      Posté par  (site web personnel) . Évalué à 1.

      Ceci dit, tu donnes juste le nom de la fonction, qui aurait pu s'appeler plop();

      Hé ho j'ai pas fait JavaSup moi. Si on veut analyser la chose il faut d'abord la récupérer, ensuite la décompacter et enfin la décompiler.
      Libre à toi d'aller traîner tes guêtres dans l'Internet interlope si tu veux.
      Mais le registrar a modifié les zones du domaine qui pointent désormais vers localhost. Faudra donc aller sur un IRC sûrement peu recommandable…

    • [^] # Re: Un 0-day de 2 jours?

      Posté par  . Évalué à 5.

      Genre, je ne suis que simple user, et je demande à mettre un bit s sur un binaire root, et que le noyau dise: ouais, vazy mon gars, tu peux le faire.

      On parle d'une faille java. À moins que tu lance ta machine virtuelle en root, il faudrait en plus exploiter une faille du noyau pour faire ce genre de chose. Je pense que c'est « juste » que du code Java peut s'exécuter sans les protections habituelles de la JVM. C'est problématique surtout problématique dans le cadre des applets Java (tiens le code de la page qui me supprimer ${HOME}). Pour le reste le SE a déjà tout un tas de sécurité comme pour les programmes natifs.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Un 0-day de 2 jours?

      Posté par  (site web personnel) . Évalué à 4.

      Un 0-day de 2 jours? C'est un 2-days alors?

      Plutôt un 4-months: http://www.techworld.com.au/article/print/435007/oracle_knew_about_currently_exploited_java_vulnerabilities_months_researcher_says/

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Ouf

    Posté par  (site web personnel) . Évalué à 5.

    The applet check if the system is running Windows

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Ouf

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      Tested on Windows XP Pro SP3 & Ubuntu 12.04 with :
      Internet Explorer 8 & Firefox 14.0.1 & Chrome
      Oracle JSE 1.7.0_06-b24

      • [^] # Re: Ouf

        Posté par  (site web personnel) . Évalué à 8.

        Et avec openjdk (vu que la java privateur on s'en cogne)?

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Ouf

      Posté par  (site web personnel) . Évalué à 2.

      Oui ça c'est celle qui a été découverte. La faille étant béante, on peut supposer que d'autres vont s'engouffrer dedans et nous proposer quelque chose de plus raffiné.

      • [^] # Re: Ouf

        Posté par  (site web personnel, Mastodon) . Évalué à 4.

        Dans le deuxième lien que tu donnes, la deuxième vidéo, on voit bien que le type peut taper des commandes unix à distances…

        • [^] # Re: Ouf

          Posté par  (site web personnel) . Évalué à 5.

          Oui parce qu'il a modifié le code html pour qu'une autre charge soit récupérée à la place de l'exe windows.
          On trouve ça dans le code source après le téléchargement:

                  if (str1.indexOf("Windows") < 0)
        {
          exec("chmod 755 " + (String)localObject1);
        }

          Ça laisse peu de doutes…

  • # limité à java 7

    Posté par  . Évalué à 10.

    Sauf erreur de ma part, c'est limité à java 7 et non java 6, il faudrait le préciser dans le journal.

  • # Commentaire supprimé

    Posté par  . Évalué à 1.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Sain & Sauf

      Posté par  . Évalué à 4.

      avez-vous des cas précis et réguliers de tels sites, à part celui des impôts ?

      Et encore je crois que pour les impôts maintenant plus besoin de java… Par contre en entreprise (enfin dans certaines) les outils maison ou les progiciels underground en applet java ça se trouve encore facilement. Et moi je me prends pas la tête à avoir un browser pour l'interne et un pour le ternet, donc ce genre de faille ça fait quand même chier (putain merde).

    • [^] # Re: Sain & Sauf

      Posté par  . Évalué à 1.

      Les seules applets Java que j'utilise sont pour des choses bien spécifiques en interne: accès aux consoles de machines HP via iLO par exemple.

      • [^] # Re: Sain & Sauf

        Posté par  . Évalué à 2.

        Mais tu utilises un browser différent (avec Java activé) pour ces choses internes bien spécifiques que celui que tu utilises pour le tout venant ? Sur internet t'es pas à l'abri de tomber sur l'une de ces applet au hasard d'un surf glissant…

        • [^] # Re: Sain & Sauf

          Posté par  . Évalué à 1.

          Honnêtement non (et je sais que c'est pas bien). Je ne vais pas sur des sites "bizarres" donc ça limite déjà pas mal (même si on est d'accord que ça n'a rien d'une sécurité absolue).
          Cela dit, pour la faille en question, comme ça ne concerne JRE 7 ce n'est pas un problème puisque je n'utilise pas cette version.

    • [^] # Re: Sain & Sauf

      Posté par  . Évalué à 1.

      Certains outils de signature électronique sont écrits en java et utilisés dans un contexte d'applet signée, ça permet de n'utiliser la clé qu'en local et de la détruire ensuite. Tu as donc théoriquement une utilisation purement locale de ta signature électronique.

    • [^] # Re: Sain & Sauf

      Posté par  (Mastodon) . Évalué à 2.

      Au passage, je n'ai personnellement encore jamais trouvé un seul site qui me donne une bonne d'activer Java : avez-vous des cas précis et réguliers de tels sites, à part celui des impôts ?

      Minecraft ! Quand on veut jouer sans laisser trop de traces, la version sous forme d'applet Java est sympa.

    • [^] # Re: Sain & Sauf

      Posté par  (site web personnel) . Évalué à 3.

      J'ai lu quelque part que certains navigateurs désactivaient le plugin s'il n'a pas été utilisé depuis plus de N jours. Ça me semble un bon compromis.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: Sain & Sauf

      Posté par  (site web personnel) . Évalué à 2.

      Applet Java : la seule à laquelle je pense en ce moment est celle fournie par la FIA pour connaître les temps au tour des Formule 1 lors d'un grand prix.

    • [^] # Re: Sain & Sauf

      Posté par  (site web personnel) . Évalué à 2.

      Les Français expatriés pouvaient opter pour le vote par internet via une applet Java lors des dernières législatives.

      Cf http://oumph.free.fr/textes/vote_internet_legislatives_2012_certificats.html
      et http://oumph.free.fr/textes/vote_internet_legislatives_2012_recus.html

  • # Quelques précisions nécessaires

    Posté par  . Évalué à -3.

    Une applet Java "simple" s'exécute dans un contexte de sécurité très restreint et n'est en mesure d'utiliser que le CPU, la RAM (jusqu'à une certaine limite), afficher son interface, recevoir les événements clavier/souris et communiquer en http/s avec son serveur d'origine - celui depuis lequel l'applet a été téléchargée.

    Pour faire plus, il faut signer l'applet et de fournir un fichier de permissions. L'utilisateur se voit alors demander s'il fait confiance à l'entité à l'origine de la signature - bien sûr s'offre à lui le choix "oui ou non" - mais sur quoi le cerveau lambda va-t-il cliquer par défaut sans même lire ?

    L'exploit dont on parle permet de court-circuiter cette contrainte de signature et l'applet s'exécute alors sans SecurityManager comme s'il s'agissait d'une application Java "de bureau" avec l'accès à toutes les ressources: systèmes de fichiers, réseau, possibilité d'exécuter du code natif… Mais cette exécution reste sous l'identité de l'utilisateur qui exécutait le navigateur et la JVM. Difficile donc de faire le rapprochement avec les setuid/setgid qui permettent de passer root.

    Voilà, donc l'exploit peut servir de porte d'entrée pour un vers, un virus ou un rootkit - qui devra obligatoirement profiter d'une autre faille au niveau du système d'exploitation pour élever son niveau de privilège du "simple utilisateur" qui tournait le navigateur vers "administrateur".

    Bien sûr, désinstaller Java est l'option idéale pour ceux: dont le système n'est pas à jour, qui se loggue en root pour naviguer sur internet, qui ont une règle sudo ALL=(ALL) NOPASSWD, mais à mon avis ça ne les protège pas plus outre mesure.

    Sinon ironie à part, mon opinion est clairement qu'un utilisateur Linux dont le poste est à jour et qui n'a pas tout le temps son accès sudo autorisé (attention à l'expiration du mot de passe !) n'a pas grand chose à craindre de ce genre d'exploit sauf peut-être si l'attaquant code un effacement récursif complet du répertoire home… mais bon, les backups sont là pour survivre à ce genre d'épreuves qui forgent le caractère.

    • [^] # Re: Quelques précisions nécessaires

      Posté par  . Évalué à 2.

      Sinon ironie à part, mon opinion est clairement qu'un utilisateur Linux dont le poste est à jour et qui n'a pas tout le temps son accès sudo autorisé (attention à l'expiration du mot de passe !) n'a pas grand chose à craindre de ce genre d'exploit sauf peut-être si l'attaquant code un effacement récursif complet du répertoire home… mais bon, les backups sont là pour survivre à ce genre d'épreuves qui forgent le caractère.

      C'est sous estimé ce que l'on peut faire avec un compte utilisateur (hormis déjà piller le contenu des données de l'utilisateur).

      Si l'on considère juste X, il est par exemple possible de mettre en place un keylogger sans sudo et sans droit root: http://superuser.com/questions/301646/linux-keylogger-without-root-or-sudo-is-it-real#334417
      Et voilà le mot de passe nécessaire pour sudo est perdu => accès root

      Si l'on prend en ligne de commande, on peut modifier le PATH ou déclarer un alias (par exemple pour exécuter plutôt un "sudo" à nous qui intercepte le mot de passe ou bien remplacer ssh pour pouvoir avoir la passphrase d'une clé) => accès root (et potentiellement accès à des serveurs distants).

      Voilà quelques idées, rapidement. Je ne doute pas qu'il y ait des milliers de possibilités.

      En résumé, non ce n'est pas aussi anodin que ton message peut le laisser penser.

      • [^] # Re: Quelques précisions nécessaires

        Posté par  . Évalué à 1.

        D'accord.

        Du coup j'ai cherché si un anti-virus sous Linux existait pour adresser certaines menaces en espace utilisateur comme un keylogger que tu mentionne. Rien de bien concluant, à part le vieux message rassurant "pas besoin d'anti-virus" sous Linux.

        Je me demande si je ne vais pas faire tourner mon navigateur en nobody dans un chroot ou encore dans une VM… La paranoïa me guette.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.