JDK-8135115 : DRS1.3: App is not blocked when there is a invalid attribute in jnlp-checksum
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-09-06
  • Updated: 2017-07-04
  • Resolved: 2015-09-10
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
8u72Fixed 9 b83Fixed
Related Reports
Relates :  
JDK-8136687 - DRS1.3: App is not blocked when rule set version is 1.0 and with jnlp-checksum element in ruleset.xml
Description
When adding cases to cover JDK-8132336, I found that:
when set invalid element in jnlp-checksum, for example <jnlp-checksum abc="BSAQgw8ZLyRFpOYiK4+mhQNJOmxmtNb8HNjTsyNvYaI="/>, no blocked dialog saying "Exception parsing Deployment Rule Set file" shows up. 

Steps to reproduce:
1. Import self ca cert to JCP -> Security -> Manage Certificates -> Singer CA.
    http://kgb.us.oracle.com:8080/DRS13Manual/lib/self.valid.cert
2. Set up DeploymentRuleSet.jar:
    http://kgb.us.oracle.com:8080/DRS13Manual/lib/DeploymentRuleSet.jar.run-Jnlp-Checksum-WithoutHash-kgb/DeploymentRuleSet.jar
    It sets a invalid element "abc" instead of "hash": <jnlp-checksum abc="BSAQgw8ZLyRFpOYiK4+mhQNJOmxmtNb8HNjTsyNvYaI="/>
    For rule set content, see http://kgb.us.oracle.com:8080/DRS13Manual/lib/DeploymentRuleSet.jar.run-Jnlp-Checksum-WithoutHash-kgb/ruleset.xml
3. Open browser and load http://kgb.us.oracle.com:8080/DRS13Manual/html/testApps.html
4. Launch casinged jnlp by clicking on the link testCertsignedAllpermissionJNLPNoHref.jnlp from a browser
5. If a valid security warning dialog shows up, then this issue is reproduced.
Expected behavior: 
An application blocked dialog saying "Exception parsing Deployment Rule Set file" should show up. For now, seems it's considered as "none match".

Note:
The same issue for:
1. Set invalid value for "hash", for example, <jnlp-checksum hash="abcdefg"/>. See http://kgb.us.oracle.com:8080/DRS13Manual/lib/DeploymentRuleSet.jar.run-Jnlp-Checksum-WrongHash-kgb/ruleset.xml
2. Set rule set version to 1.0 and with jnlp-checksum element in ruleset.xml. See http://kgb.us.oracle.com:8080/DRS13Manual/lib/DeploymentRuleSet.jar.run-Jnlp-Checksum--Version-kgb/ruleset.xml
3. Set empty hash valure, for example, <jnlp-checksum hash=""/>.
Comments
Verified with jre9-b175 on win10/x64.
04-07-2017
Verified with http://jre.us.oracle.com/java/re/jdk/9/jdk9-client/b82_2015-09-15-0923_3389/bundles/ on win7/x64: most fixes work fine. But I found that "ruleset version=1.0"+"jnlp-checksum" issue is still there. Filed a new bug to track remaining issue: JDK-8136687.
17-09-2015
1.a, 2.a, and 3.a above are implemented as in crucible review: https://java.se.oracle.com/code/cru/CR-JDK9CLIENT-1330
09-09-2015
There are 3 potential problems here 1.) an unexpected, unknown attribute is used, such as "abc" above. 2.) a <jnlp-checksum> element occurs without a "hash" attribute. 3.) the "hash" attribute has a value that cannot be a valid SHA-256 hash of anything. 1.) this is clearly not a bug. If an unknown attribute is found anywhere in a drs xml file, an unchecked trace statement is executed saying: ""Warning: Unexpected attribute \"" + qName + "\" for element \"" + elementName + "\" found when processing the Deployment Rule Set."); The DRS is never considered invalid for an unexpected attribute. There is, however, a bug here, as this unchecked trace statement will be printed for a valid "hash" attribute, since the code processing the attribute does not add "hash" to the "validAttributes" array list: 1.a) extra unchecked trace statement for jnlp-checksum element with hash attribute. 2.) Since the DRS 1.3 DTD lists hash as a required attribute of jnlp-checksum: <!ATTLIST jnlp-checksum hash CDATA #REQUIRED> the behavior should be the same as for other required attributes.such as "hash" on a checksum or certificate element, or "permissions" in an action. I find these behaviors inconsistent, the first two will cause some sort of parsing exceptiobn to be thrown, but not directly from missing the required attribute. I looks from code like an action with no permission will slip thru but I need to test 2.a) make any missing attribute required by the DTD to be a parsing error. 3.) Generally, the value of an attribute that is defined as CDATA is not sanity checked, just used to compare to whatever it is attempting to match against., but Management dictated several rules that could make a DRS xml file invalid: * 1.) cannot have a run everything rule. * 2.) cannot have a run or default rule based only on the title * 3.) if rule only has location, that is allowed, but if location is not https based, warn developer that https is recommended. * 4.) cert hash: non-empty, valid hex digits, 64 characters (if SHA-256) * 5.) checksum hash: non-empty * 6.) title: non-empty, 140 characters max * 7.) location URL: protocol in {http, https, file or no protocol}, max length of 256 characters Since this is similar to either a checksum hash, we will follow the same rule - just insure string is not empty. 3.a) expand validateRule() to require all values for "hash" attribute in "jnlp-checksum" attribute to be non-empty string.
09-09-2015
Affected tests: RULE JawsLocalSecurityPolicyTest::testJnlpChecksum_Negative_EmptyHash any any RULE JawsLocalSecurityPolicyTest::testJnlpChecksum_Negative_RuleSetVersion any any RULE JawsLocalSecurityPolicyTest::testJnlpChecksum_Negative_WithoutHash any any RULE JawsLocalSecurityPolicyTest::testJnlpChecksum_Negative_WrongHash any any
09-09-2015