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 René Quirion . En réponse au journal Java ça pue c'est trop libre.. Évalué à 2.
Tout à fait.
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".