Java 7u4 webstart安全异常：类与信任级别不匹配

Question

我们开始注意到，对于Java 7（尤其是update 4），我们的所有用户都开始在我们的Webstart应用程序中看到这一点：

[14:42:58,422] AWT-EventQueue-0(DEBUG) java.lang.SecurityException: class "CLASSNAME" does not match trust level of other classes in the same package
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.deploy.security.CPCallbackHandler$ChildElement.checkResource(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.deploy.security.DeployURLClassPath$JarLoader.checkResource(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.net.URLClassLoader$1.run(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.net.URLClassLoader$1.run(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.security.AccessController.doPrivileged(Native Method)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.net.URLClassLoader.findClass(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.lang.ClassLoader.loadClass(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.lang.ClassLoader.loadClass(Unknown Source)...More

其中CLASSNAME=几乎每个类都在应用程序执行中的几个JAR中的任意点上，破坏了几个行为。 如果我们的用户使用Java6，他们就没有问题了！只有7个（更新4）。 我们对所有jar进行签名，包括主应用程序jar和它的库jar。i、 e启动我们的webstart应用程序的用户看到的是蓝色的盾，而不是黄色或红色

这显然是一个问题，因为用户现在更频繁地升级到Java7。 我试图通过使用以前的安装（works）或安装新的安装，强制我们的应用程序在用户机器上使用Java6。。。。使用j2se version=“1.6”标记来标记资源，但这会导致它自身的问题，最好将这些问题添加到它自己的线程（自动jre安装部分）中

Oracle是否使用Java 7u4破坏了Webstart安全性？如何解决此安全异常问题

Answer 1

只是jarsigners黑客登录的原始作者。我在这里是由另一个开发人员指导的，我最初与他分享了这个黑客程序

根据他对此事的持续调查，你需要在黑客电话中添加以下内容

callNoArgMethod("getSigningData", jar);
makeHardLink("signingDataRef", jar);

callNoArgMethod("getManifest", jar);
makeHardLink("manRef", jar, n);

清单调用不是此帖子解决方案的一部分。在创建验收测试以重新处理问题时发现了这些问题

基于这一新信息，我们改变了方法，现在我们使用反射来调用所有“get”方法（如果尚未填充softreference，则需要调用get方法来最初填充它们）

然后反射性地发现CachedJarFile类中的所有软引用，并创建指向它们的硬链接

只要CachedJarFile保持不变，且黑客攻击的基本前提保持不变，这将证明解决方案将来可以通过进一步的内部重命名/重构来实现。（即：把软参考变成硬参考

Answer 2

我想你可能正在经历this bug

bug状态显示已在7u4中提供修复程序。但这与你所说的不符。也许“修复”失败了

与此同时，“squaat”对该漏洞的评论提到了可能的解决方法。例如，增加初始堆大小和/或使用预加载程序强制提前加载一些JAR

Answer 3

我一直在使用JRE 7u5与同样的症状作斗争。使用JRE 6u33，完全相同的web应用程序启动时没有出现问题

在我的例子中，问题是由我的一个扩展名jnlp文件引起的。主jnlp文件指定了所有安全权限，而扩展jnlp没有声明任何特定的安全要求（只是一个空的安全标签）

这导致扩展jar被加载到沙箱中。显然，Java 7不接受混合具有不同安全要求的JAR，即使它们都经过签名

通过确保所有扩展名jnlp文件都指定了与主jnlp文件相同的安全要求，问题得到了解决

Answer 4

我在1.7.07中遇到了同样的问题：我的webstart应用程序在加载类时随机失败，并显示相同的错误消息。我在这个页面上找到了一个有趣的解决方法。 最后一个答案描述了该问题的解决方法（Java 6）——对JAR签名的引用被保留为软引用，这些引用可能被垃圾收集，这会导致错误消息。这可以通过一些额外的行应用于Java7

// Java 1.7
callNoArgMethod("getSigningData", jar);
makeHardLink("signingDataRef", jar); 

Answer 5

在升级到JRE 8 update 91后，我也遇到了同样的问题。在之前的1.6、1.7、1.8版本中，我的应用程序运行良好

Oracle是否重新引入了JRE 1.6bug中存在的错误

我发现的唯一解决方法是从Java控制面板禁用混合代码控制

---

我修好了。问题出在我的应用程序使用的库中。 舱单。罐子里的MF是这样的：

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0
Created-By: 1.5.0_07-87 ("Apple Computer, Inc.")
Built-By: wolf

Name: common
Specification-Title: swixml
Specification-Vendor: swixml.org
Specification-Version: 1.6
Implementation-Title: org.swixml
Implementation-Vendor: swixml.org
Implementation-Version: 1.6 beta 1 (#151)

“Name”属性用于此处所述的特定于资源的条目http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#JAR_Manifest

为这个jar签名“Name”条目被解释为一个资源，但没有可签名的资源。 当应用程序启动时，javaws发现清单中报告的资源不匹配。MF和jar中阻止应用程序的有效资源