JDK-8054971 : Applet is blocked when requesting sandbox permission and loading loose resource
  • Type: Bug
  • Component: deploy
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-08-13
  • Updated: 2015-06-03
  • Resolved: 2014-09-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u40 b06Fixed 9Fixed
Description
1. Install jre9 nightly build from 
http://jre.us.oracle.com/java/re/jdk/9/jdk9-client/latest/bundles/windows-i586/jre-9-ea-windows-i586.exe
2. Download http://sqeweb.us.oracle.com/net/sqenfs-1/export1/comp/quality1/deployment2/larry/tmpcert/self.valid.cert and import into keystore:
"c:\Program Files (x86)\Java\jre1.9.0\bin\keytool.exe" -import -file self.valid.cert -keystore "c:\Program Files (x86)\Java\jre1.9.0\lib\security\cacerts" -storepass changeit -alias validSelfSign -noprompt
3. In browser load applet:
http://sqeweb.us.oracle.com/net/sqenfs-1/export1/comp/quality1/deployment2/larry/appletattack/html/testZeroWidthGifImage.html
4. If the applet is blocked, the issue is reproduced.
The applet is signed with trusted certificate and requesting sandbox permission. The same applet can load fine with 8u25 b11.
Comments
Verified in 8u40 b08 1. Install JRE 8u40 b08 2. Download http://sqeweb.us.oracle.com/net/sqenfs-1/export1/comp/quality1/deployment2/larry/tmpcert/self.valid.cert and import into keystore: "C:\Program Files (x86)\Java\jre1.8.0_40\bin\keytool.exe" -import -file self.valid.cert -keystore "C:\Program Files (x86)\Java\jre1.8.0_40\lib\security\cacerts" -storepass changeit -alias validSelfSign -noprompt Certificate was added to keystore 3. In browser load applet: http://sqeweb.us.oracle.com/net/sqenfs-1/export1/comp/quality1/deployment2/larry/appletattack/html/testZeroWidthGifImage.html
03-10-2014
note - bug is targeted to 8u30 (and 9). not yet reproducible in 8u40, since 8023999 is not yet back-ported - but same will apply anywhere 8023999 is back-ported to.
28-08-2014
webrev: http://oklahoma.us.oracle.com/www/webrevs/aherrick/1.9.0/8054971/ test cases: http://oklahoma.us.oracle.com/www/tests/1.9.0/8054971/bug.html
27-08-2014
The best solution I have is as follows: When unsigned code would block: 1.) we will show unsigned dialog when loading loose resource. 2.) we will continue to block when loading resource from a jar. The only case where we show unsigned dialog and then block anyway, is if a signed applet loads a loose class. We will no longer block for signed applet loading a loose non-class resource. When unsigned code would not block, but show security dialog (such as pre-8u20 MEDIUM security level, or app is on ESL) we will show unsigned dialog whether resource is class or non-class, regardless of if it is in jar or loose.
27-08-2014
response from security: Security-wise I'm fine with either blocking or prompting for unsigned resources, though blocking sounds like it might be a usability problem. I'm really not sure how to get around the issue you mention without a lot of changes to resource loading (e.g. somehow signifying/determining that the resource loading request is coming from a class loading method, or alternatively making an internal resource loading method that does not prompt, which would allow the calling method to handle prompting). These approaches seem like they would require a fair bit of refactoring though and could potentially be messy.
20-08-2014
We still have not reached a conclusion on this. With JDK-8023999, loading an unsigned non-code resource will show a security dialog in JDK9 As a side effect, when unsigned code is blocked, loading an unsigned non-code resource will also block. Should this block or show security dialog ? If the answer is to show security dialog, we have the following problem: When loading unsigned code, we first go thru loadResourceAsStream(), where we do not know if the resource will be used as code or not. As a result we would show security dialog first, then when we reach getPermissions() we would block. I do not know how in getResourceAsStream() we can know if the resource will be used as code or non-code resource. The behavior of first showing unsigned dialog, then blocking as unsigned code, is not acceptable.
20-08-2014
This is a failure due to new security feature in 9: JDK-8023999 applet is loading loose resource from codebase, intent of JDK-8023999 is to show unsigned security dialog - but unsigned code is prohibbited, so we block. needs further study.
13-08-2014