A Different Form of JAR Hell

In my last post I used a Java applet to steal password hashes. Part two, covering NTLMv2, is on its way. Today however, I'm going to discuss SunSolve #233323 - a vulnerability that was fixed in the March updates to the JRE. Anyone who caught my ToorCon talk will have already heard me discuss this issue.

Java Web Start has provision for resources, signed JAR files that contain either Java classes or native libraries that can be cached for use by one or more applications. JARs containing Java classes are extracted as per the usual Java caching mechanism (i.e. written to disk using randomly generated names) whereas native libraries are extracted with their original filenames. Interestingly filenames can include parent path sequences (e.g. ..\..\..\..\test.txt). This means that "nativelibs" can be written outside the cache folder. But that's ok because nativelib resources need to be signed and therefore explicitly trusted by the user, right?

Not exactly. Take a look at the following code snippet, which resembles the vulnerable Java Web Start code, and see if you can spot the bypass (it's not exactly obvious):

try
{
 // Open the JAR file specifying true to indicate
 // we want to verify the JarFile is signed.
 JarFile jf = new JarFile(UserSuppliedFile, true);

 Enumeration e = jf.entries();
 while (e.hasMoreElements()) 
 {
  ZipEntry ze = (ZipEntry) e.nextElement();
  InputStream i = jf.getInputStream(ze);
  byte b[] = new byte[i.available()];
  i.read(b);

  // Call our method to write the bytes
  // to disk

  WriteFileToDisk(ze.getName(), b);
 }
}
catch (SecurityException se)
{
 // Some sort of signature verification error
 System.out.println("Security Error: " + se.toString());
}
catch (IOException ioe)
{
 System.out.println("File Error: " + ioe.toString());
}

If you spotted the problem, well done! If not, here's a hint courtesy of an IBM article on signed JARs:

Each signer of a JAR is represented by a signature file with the extension .SF within the META-INF directory of the JAR file. The format of the file is similar to the manifest file -- a set of RFC-822 headers. As shown below, it consists of a main section, which includes information supplied by the signer but not specific to any particular JAR file entry, followed by a list of individual entries which also must be present in the manifest file. To validate a file from a signed JAR, a digest value in the signature file is compared against a digest calculated against the corresponding entry in the JAR file.

What if a file doesn't have a corresponding manifest entry? It turns out the above code will happily call WriteFileToDisk anyway and there'll be no exception thrown. We can use this bypass to append a file to a signed resource and have it drop a java.policy file in the user's home directory allowing applets and Web Start applications to do bad things.

Let's take a look at how the Jarsigner tool that ships with the JDK validates signed JARs. Jarsigner correctly detects JARs containing both signed and unsigned content:

The code snippet below shows the enumeration of ZipEntrys; it's taken from sun.security.tools.JarSigner:

Enumeration e = entriesVec.elements();

long now = System.currentTimeMillis();

while (e.hasMoreElements()) {
 JarEntry je = (JarEntry) e.nextElement();
 String name = je.getName();
 CodeSigner[] signers = je.getCodeSigners();
 boolean isSigned = (signers != null);
 anySigned |= isSigned;
 hasUnsignedEntry |= !je.isDirectory() && !isSigned 
       && !signatureRelated(name);

The code retrieves the entry's CodeSigners; if there are none the entry is deemed unsigned.

As an aside, it's actually possible to fool Jarsigner. Take a look at the signatureRelated method, which is called above:

    /**
     * signature-related files include:
     * . META-INF/MANIFEST.MF
     * . META-INF/SIG-*
     * . META-INF/*.SF
     * . META-INF/*.DSA
     * . META-INF/*.RSA
     */
    private boolean signatureRelated(String name) {
 String ucName = name.toUpperCase();

 if (ucName.equals(JarFile.MANIFEST_NAME) ||
     ucName.equals(META_INF) ||
     (ucName.startsWith(SIG_PREFIX) &&
  ucName.indexOf("/") == ucName.lastIndexOf("/"))) {
     return true;
 }

Jarsigner ignores unsigned files that start with the prefix "META-INF/SIG-":

Anyway, back to the Web Start issue. Soon after discovering this bug I realised it was effectively moot for I hadn't seen any security dialogs even when working with fully signed JARs. It turned out there were none. Ever. You could simply even use a self-signed JAR! Still, it's a great example of a managed language providing a simple interface (JarFile) that masks a complex implementation; if the contract between the caller and the callee is not clearly defined (however simple the interface), developers can write insecure code without knowing it.

So that's it for now. There's also some interesting behaviour when loading applets containing signed and unsigned content but I'll save that for another day.

Cheers

John

p.s. In case you were wondering, JAR hell is Java's form of DLL hell.