-
Bug
-
Resolution: Fixed
-
P1
-
1.1.1
-
None
-
1.1.5
-
generic
-
generic
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2016602 | 1.2.0 | Roland Schemers | P1 | Resolved | Fixed | 1.2beta2 |
Redirects happen in the networking layer, so sun.applet.AppletClassLoader
happily allows them to happen. This leads to an attack where a site
outside the firewall causes some class C to be loaded. The attacking
server can redirect http://evil.com/C.class to some site behind the
firewall -- say http://javaweb.eng.sun.com/C.class. Assuming it's there,
now the applet (some of whose classes came from the attacking site) can access
potentially sensitive information from C.class.
Similarly, we allow Jar files to come from an arbitrary URL, at a host completely
unrelated to the codebase. This leads to a similar attack.
happily allows them to happen. This leads to an attack where a site
outside the firewall causes some class C to be loaded. The attacking
server can redirect http://evil.com/C.class to some site behind the
firewall -- say http://javaweb.eng.sun.com/C.class. Assuming it's there,
now the applet (some of whose classes came from the attacking site) can access
potentially sensitive information from C.class.
Similarly, we allow Jar files to come from an arbitrary URL, at a host completely
unrelated to the codebase. This leads to a similar attack.
- backported by
-
JDK-2016602 RMI and AppletViewer allow .class file redirects and JARs from other sites
-
- Resolved
-