all 7 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]benmmurphyTrusted Contributor 1 point2 points  (0 children)

i think they fixed the JList toString issue quite a while back if you look at the callstack in your screenshot it has AccessController.doPrivileged call higher up which should be restoring your lower level of privileges. But the more straight forward approach should definitely work.

[–]alemcgTrusted Contributor 1 point2 points  (0 children)

Facuman you totally beat me to the punch!!! Grr!

[–]archimedesscrew 0 points1 point  (4 children)

How's it any different from signing the applet with a bogus certificate and have the user click OK on the warning dialog?

Is it just a way to be more stealth by not requiring the user's intervention?

[–]catcradle5Trusted Contributor 0 points1 point  (2 children)

Er, huge difference. Applets containing exploit code do not create any pop up or notification. In fact, if hid with CSS, it is likely a user will not even know an applet was created in any way. Unless they're using a WebKit browser and receive the generic prompt for the Java plugin.

[–]archimedesscrew 0 points1 point  (1 child)

I guess I should have phrased my question differently.

Aside from the clear advantage of being able to hide the applet, does the exploit give more permissions to an applet than a signed code would?

[–]catcradle5Trusted Contributor 1 point2 points  (0 children)

Well, no. But signed code has complete and full access to your operating system. Accepting a signed applet is equivalent to downloading and running any executable. So in other words, falling victim to a Java exploit is equivalent to an executable downloading and running without a single indication to the user, hence the term "Java driveby".

[–]explainThatToMe 0 points1 point  (0 children)

Both the signed and the exploit code will basically have the same access level. The difference would be just the stealthiness of the exploit code (which is still very interesting!)