Java 7u4 WebStart安全异常：类不符合信任级别

Question

我们注意到使用Java 7 (尤其是更新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中的随机点选择所有类时，会破坏一些行为。如果我们的用户使用Java 6，则没有问题！只有7（更新4）会出现问题。

我们签署了所有JAR文件，包括主应用程序JAR和其库JAR。即用户启动我们的Webstart应用程序时，看到的是蓝色盾牌而不是黄色或红色。

显然，这是一个问题，因为用户现在更频繁地升级到Java 7。我尝试强制用户机器上的应用程序使用Java 6，方法是在资源周围使用j2se version="1.6"标签(可以解决问题)，或者安装一个新版本....但这会导致自动JRE安装部分出现问题，最好将其转化为单独的主题来讨论。

Oracle是否在Java 7u4中破坏了Webstart安全性？如何解决此安全例外问题？

- Glstunna

---

我们在2014年8月最新的JDK中仍然看到这些症状。Oracle已经将其标记为已修复。还有其他人仍然看到这个问题吗？是否有可靠的测试用例来引发此问题，以便我们可以验证修复情况？ - KC Baltz

Answer 1

我曾经遇到过1.7.07版本的问题：我的WebStart应用程序在加载类时会随机失败，并显示相同的错误消息。我在Oracle论坛上找到了一个有趣的解决方法。最后一个答案描述了一个问题（Java 6）的解决方法-将JAR文件的签名引用保存为软引用，这些引用可能被垃圾回收，从而导致出现错误消息。这种方法可以通过添加一些额外的代码来适用于Java 7。

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

- Some One

Answer 2

我是jarsigners破解的原作者，现在过来报到。我是被另一个开发者引荐过来的，当初我就是和他分享了这个破解方法。

根据他持续的调查，你需要在使用这个破解方法时添加以下内容：

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

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

这篇文章并未涉及到清单调用。在重现此问题的验收测试中，我们发现了这些调用。

基于这个新信息，我们改变了方法。现在我们使用反射来调用所有的“get”方法（对“get”方法的调用是必需的，以便初始化软引用，如果它们还没有被初始化）。

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

只要CachedJarFile保持不变且该黑客的基本前提仍然成立（即：将软引用转换为硬引用），这样做应该可以使解决方案免受进一步的内部重命名/重构的影响。

- squaat

Answer 3

我认为您可能正在遇到这个bug。

该bug状态显示修复已在7u4中发布。但这与您所说的不符。也许“修复”会破坏...。

同时，“squaat”在bug上的评论中提到了可能的解决方法。例如，增加初始堆大小和/或使用预加载器来强制一些JAR文件更早地加载。

- Stephen C

Answer 4

我在升级到JRE 8更新91后遇到了同样的问题。在之前的版本1.6、1.7和1.8更新77中，我的应用程序都可以正常运行。

Oracle是否重新引入了在JRE 1.6中存在的漏洞 bug？

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

---

我已经解决了问题。问题出在我的应用程序使用的一个库中。 在jar包中存在的MANIFEST.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发现MANIFEST.MF中报告的资源与jar文件中的实际资源不匹配，从而阻止应用程序运行。

- CARCARLO

Answer 5

我一直在使用JRE 7u5时遇到了相同的问题。但是，当我使用JRE 6u33时，完全相同的Web应用程序可以无问题地启动。

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

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

通过确保所有扩展jnlp文件指定与主jnlp文件相同的安全要求来解决了这个问题。

- pst

---

我们只使用一个jnlp文件，没有扩展。 - Glstunna