2

When we say that Java applets are vulnerable, what exactly do we mean? A vulnerability in the underlying jre? In the browser? In the "applet" component?

what exactly is exploited?

3

Classes of Java Applet vulnerability

Vulnerabilities in the Applets themselves

This would include issues with how the applet is written, such as:

  • Backdoors
  • Cross Site Scripting
  • Cross Site Request Forgery

Vulnerabilities in the Browser and JRE

This would include issues with allowing the running of Java applets, such as:

  • Ability to track users
  • Ability to perform malicious actions
  • Sandbox escapes

Why are Java applets so bad

Trying to sandbox the applets is hard, and as such there will be edge cases allowing sandbox escapes. As most of the things that web pages need to do can be done without adding the extra vulnerabilities, it makes sense to try to disable applets, as this reduces the attack surface.

  • so there could be vulnerabilities in either JDK (used for writing the applet),JRE, and/or the browser. To pull off an exploit, you have to have a combination of all of these to succeed or is just a single component, any of these, sufficient? – microwth Oct 12 '18 at 21:29
  • also,is the java plugin the same as a Java applet,or is the plugin the one that runs the applet? – microwth Oct 12 '18 at 21:38
  • 1
    The plugin is the one that runs the applet, JDK vulns would require the victim to compile the applet, which is rare for end ussers. Depending on the exploit you may be able to just use an applet (attacking an internal app), or may need to use a plugin vuln to break out of the sandbox – jrtapsell Oct 13 '18 at 11:33
  • 1
    Sandboxing applets would be easy (the library part, not necessarily the JVM - though that has proven largely robust) if it were not for concessions for "corporate developer" (specifically global state, a.k.a. statics). The Object Capability Model is well understood on account of being trivial. / Trusted applets have a similar set of issues to Browser and JRE, except they have little or no scrutiny and are typically written by corporate developers. – Tom Hawtin - tackline Oct 13 '18 at 22:59
  • 1
    An example of a JDK issue (where JDK not part of deployment) is 1.1.0 remove the private flag from members accessed by inner classes. Fixed in the JRE (by making the smallest unit of trust the runtime package instead of class/interface). – Tom Hawtin - tackline Oct 13 '18 at 23:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.