Abstract
This paper underlines a current vulnerability which is caused by the integration of the Apache XPath component into the core functionality of the JDK.
XML-Sniffing
Since JDK 1.4.1 XML parsing and transformations of XML are an integral part of
the core functionality. In contrast to other parts of the JDK this functionality was
imported from a third party namely the xalan and xerces components (which we are
refering to as XXC in the following discussion) from the apache group. For XML related purposes
XXC provide a wide range of interfaces, classes and tools.
As far as security is concerned the XXC do not follow the security guidelines which
were published by Sun 1 and are recalled in brevity in the following table, the violated
guidelines in the XXC are marked with an X.
| R1 | Static fields | X |
| R2 | Reducing scope | X |
| R3 | Public methods and fields | X |
| R4 | Protecting packages | |
| R5 | The Equals method | X |
| R6 | Make objects immutable if possible | |
| R7 | Never return a reference to an internal array that contains sensitive data | X |
| R8 | Never store user-supplied arrays directly | |
| R9 | Serialization | |
| R10 | Native methods | |
| R11 | Clear sensitive information |
Problems with static fields
To recall Sun suggests to be careful when defining static fields.
- Refrain from using non-final public static variables, because there is no way to check whether the code that changes such variables has appropriate permissions.
- Bbe careful with any mutable static states that can cause unintended interactions between supposedly independent subsystems
In XXC the problem occured that typically arises when static non-final fields are used, which is uncontrollable access by other components. As XXC are loaded only once per JVM and are part of the TCB this is a problem when multiple processing entities share a JVM, which is the case in when applets from separate web sites. Sandboxing as code containment technique is typically used to separate address and naming spaces of di erent applets when sharing the same JVM. Communication between applets from different sites should not be possible. To detect the candidate fields that are accessible via non-final static variables the BCEL was used.
According to an recommendation document of the World Wide Web Consortium (W3C) the XPath standard is defined as follows:
The primary purpose of XPath is to address parts of an XML [XML] document. In support of this primary purpose, it also provides basic facilities for manipulation of strings, numbers and booleans. XPath uses a compact, non-XML syntax to facilitate use of XPath within URIs and XML attribute values.
Attack preparations
The org.apache.xpath package is a common implementation of XPath functionality. In org.apache.xpath.compiler.FunctionTable the field m_functions is declared public. Every class loaded by the primordialy class loader (PCL) is loaded only once into the JVM, which is contrast to user class loaders where the same class definition can be loaded multiple times into the JVM.
As a PCL-loaded class is a strict singleton its de ned static elds are strict singletons, too. A public static non-final field which is loaded from the primordialy class loader (PCL) is accessible from the entire address space of the JVM. This allows every class to manipulate the value and changes will influence the behavior of the package for the entire JVM.
CODECODECODE
The contents of the m_functions array determines which java functions (of the type FuncLoader) are called when certain XPath are encountered by the Xpath compiler.
An attacker can forge his own functions to be called by replacing the existing
default functions in the m_functions array by his functions. To prevent detection an
attacker may choose to override an existing implementation class of an Xpath function,
such as the implementation of the often used position() function. Providing
the expected functionality and additional sning provides a less obvious environment
for the attack.
The position() function is implemented by the class FuncPosition in the package
org.apache.xpath.functions. To reach his goal the attacker could register an
extended version of the FuncPosition class like the proof-of-concept implementation
shown in XXX. A more advanced version would collect the data or send it via a http
request to its originating host, which is the only accessible remote contact point due
to sandbox restrictions.
CODECODECODE
After definition of this class the attacker defines a modified subclass of the FuncLoader
to adjust the bypass the classloading checks of the original FuncLoader implementation.
After these preparation the attacker codes an applet to inject his code
to the JVM inside the victim's browser.
The applet SniffingApplet is coded as follows:
This applet once loaded within a web page by a browser registers the enhanced
implementation of the XPath position() instruction. After the class is registered
it stays in the JVM until the browser is closed, it is not collected by the garbage
collector, even when the originating applet is closed because the injected instance of
the MyPosition class is still referenced by the FunctionTable. While being registered
as a XPath function handler the MyPosition object is able to read all data which is
passed to the xctxt object during XPath processing. The following applet and data
can be used to illustrate the resulting violation of the sandbox.
A user loads a second applet after he inconsciously started the SniffingApplet.
CODECODECODE
The second applet is performing XML transformation with the embedded XML classes
of JDK. For simplicity the example applet XSLTProcessorApplet which bundled with
JDK is used.
The XSLTProcessorApplet is started with the following HTML code.
The applet from Transform.html receives two parameters, the XSL stylesheet
Address.xsl and the XML data which is stored in Addressbook.xml
Proof-Of-Concept
When the second applet is started the data structures which are evaluated by the position() are sniffed and can be used by the SniffingApplet. The sandbox protection is broken and XML/XSLT/XPath processing in applets should therefore be considered as unsafe when the apache classes bundled with the JDK are used. In this context it makes no di erences whether codebases are signed or even SSL is used for transmission as the confidentiality comprimise occurs directly in the shared ressource, which is the JVM. The following stack trace demonstrates how the MyPosition class is incorporated in the XSLT processing call stack.
CODECODECODE
Refactoring
A refactored solution should block the possibility to add own functions to XPath
processing as this can break sandbox isolation.
The following refactorings should be considered:
- add the final modifier to the definition of the FuncLoader class.
- encapsulate the m_functions dispatching array of FuncTable behind an immutable
proxy class.
Conclusion
This paper demonstrated another of java insecurity due to coding antipatterns, in
particular violating against the secure coding principles of Sun Microsystems. The
demonstrated vulnerability shows that the reused XPath component from the apache group did not meet the secure coding requirements set by the published guidelines
by Sun Microsystems which lead to security compromise.