Possible arbitrary code execution in the Tags implementation in Eclipse WaSP and Eclipse Glassfish
We have received the following from Tags committers:
Hello Eclipse Security Team,
It appears to us (Tag committers) that there may be a vulnerability in the Tags implementation. It is formerly known as JSTL.
The implementation project currently resides in WaSP: https://github.com/eclipse-ee4j/wasp/tree/master. However, it previously resided in: https://github.com/jakartaee/tags.
This vulnerability relates to CVE-2015-0254 (1), which was reported against Apache Taglibs, but Glassfish's implementation also addressed it.
The fix in Glassfish was to set FEATURE_SECURE_PROCESSING (FSP) (2) on the parsers in order to restrict external connections by default. The problem, however, is that JDK/XML implementations are only recommended to restrict external connections. They are not mandated (however, the majority of those we tested do follow the recommendation). For example, OpenJDK 8 follows the recommendation, but IBM JDK 8 does not. If it runs on earlier Java runtimes (for those who haven't upgraded), then FSP may not be applicable. For example: 'org.glassfish.web:javax.servlet.jsp.jstl:1.2.5' was compiled against Java 5.
The specification text under "ACCESS_EXTERNAL_DTD" (3):
When FEATURE_SECURE_PROCESSING is enabled, it is recommended that implementations restrict external connections by default, though this may cause problems for applications that process XML/XSD/XSL with external references. In essence, FEATURE_SECURE_PROCESSING may not always work as it is implementation dependent, and we believe there should be a stricter fix. This recommendation is carried to Java 21 (4).
We also wish to provide some background on the Apache Fix:
It relied on the FEATURE_SECURE_PROCESSING configuration for Java 8 runtimes or higher. For Java 7, it requires specific JAXP properties, such as javax.xml.ACCESS_EXTERNAL_DTD. For Java 6 and earlier, it created a new property, "org.apache.taglibs.standard.xml.accessExternalEntity". This property defaulted to "all" (allow external entities), and "" (restrict access) if the security manager was present.
This fix also appears problematic to us. As mentioned, we are also unsure if developers knew the FEATURE_SECURE_PROCESSING was not mandatory. Secondly, the apache property is always checked during resolving entities, regardless of the Java runtime. If the security manager is present, then the access will be denied prior to the FSP check. Otherwise, to allow access (with the security manager enabled) the apache property would need to be set to true and the system property, javax.xml.ACCESS_EXTERNAL_DTD, would also need to be set to true. If FSP is not honored, then external access can still occur unless the security manager is enabled. With the security manager now being deprecated, the fix only relies on the non-mandatory FSP attribute once again.
Alternatively, developers would need to ensure their application is run with the system property javax.xml.ACCESS_EXTERNAL_DTD="" in order to avoid external access which may be overreaching if it's only meant to address JSTL/Tags.
This fix for Apache Taglibs is not straightforward and requires a bit of knowledge of JAXP properties and interactions with the security manager.
The full migration advice can be read here: https://lists.apache.org/thread/6d8pyrwsmyokxstl9x7py02kq2d3rbom
In short, we would like your opinion on whether CVE-2015-0254 should be looked at again for the JakartaEE Tags Impl and its reliance on only FSP.
Thank you,
Volodymyr Siedlecki & Paul Nicolucci
-
https://nvd.nist.gov/vuln/detail/CVE-2015-0254 : "allows remote attackers to execute arbitrary code or conduct external XML entity (XXE) attacks via a crafted XSLT extension in a (1) <x:parse> or (2) <x:transform> JSTL XML tag."
-
https://docs.oracle.com/javase/8/docs/api/javax/xml/XMLConstants.html#FEATURE_SECURE_PROCESSING
-
https://docs.oracle.com/javase/8/docs/api/javax/xml/XMLConstants.html#ACCESS_EXTERNAL_DTD