SEC05-J. Digitally sign all artifacts before deployment

Java based technologies typically use the Java Archive (JAR) feature for packaging files to facilitate platform independent deployment. Be it desktop applications, Enterprise Java Beans (EJB), MIDlets (J2ME) or Weblogic Server J2EE applications, for example, jar files are the preferred distribution mechanism. The point and click installation provided by Java Web Start also relies on the jar file format for packaging.

It is in the interest of the user to verify the authenticity and integrity of the artifacts that they wish to deploy. At the same time, it is the software vendor's responsibility to ensure that all files, supporting documents like help files, installation instructions and other software artifacts, are digitally signed to thwart man in the middle attacks. Likewise, any software updates or patches must be signed by the vendor and verified explicitly by the preexisting software implementation at the remote user's side, usually without any user intervention.

According to [[Tutorials 08]]:

If you are creating applet code that you will sign, it needs to be placed in a JAR file. The same is true if you are creating application code that may be similarly restricted by running it with a security manager. The reason you need the JAR file is that when a policy file specifies that code signed by a particular entity is permitted one or more operations, such as specific file reads or writes, the code is expected to come from a signed JAR file. (The term "signed code" is an abbreviated way of saying "code in a class file that appears in a JAR file that was signed.")

Noncompliant Code Example

This noncompliant example creates the jar file but does not address code signing through digital signatures. Anyone can replace the package or individual files with malicious code while the file is in transit.

jar cfm updates-jar-file.jar Manifest.txt input-file(s).class

Compliant Solution

The jarsigner tool is used to digitally sign jar files. To do this, it uses key and certificate information from a keystore. This compliant solution shows how to sign the jar file that was generated in the noncompliant code example. The URL of the keystore kstore follows the -keystore flag. The -signedjar option can be used to specify a different name for the signed archive to be generated. The private key associated with the alias user, will be used to digitally sign the jar file.

jar cf updates-jar-file.jar input-file(s)
jarsigner -keystore /home/kstore.jks -storepass password1 -keypass userpassword
-signedjar signed-updates-jar-file.jar updates-jar-file.jar user

Noncompliant Code Example

Naturally, equally important is verifying the signature at the client side. Depending on how the client code works, signatures may or may not be automatically checked. For instance, any instances of URLClassLoader and its subclasses and java.util.jar automatically verify a signature whenever the jar file appears to be signed. If however, the developer implements a custom classloader that goes on to subclass the ClassLoader, this step is not performed automatically. Moroever, the automatic verification just involves an integrity check and does not authenticate the loaded class. This is because the check uses a public key that is contained within the jar. This public key can be easily replaced with a new one and the other files can be tampered with to reflect the hashes computed over the malicious class file.

This noncompliant code example demonstrates the JarRunner application [Tutorials 08] that can be used to dynamically execute a particular class residing within a jar file. It creates a JarClassLoader that loads an application update, plugin or patch over an untrusted network such as the Internet. The URL to fetch the code is specified as the first argument (for example, http://somewebsite.com/software-updates.jar) and any other arguments specify the arguments that are to be passed to the class to be loaded. Reflection is used to invoke the main method of the loaded class.

Unfortunately, there are no built in checks for verifying the signature. Any man in the middle can construct a class that will run with the permissions specified for this code source in the policy file.

public class JarRunner {
  public static void main(String[] args) {
    if (args.length < 1) { usage(); }
    URL url = null;
    try {
      url = new URL(args[0]);
    } catch (MalformedURLException e) { fatal("Invalid URL: " + args[0]); }
    // Create the class loader for the application jar file
    JarClassLoader cl = new JarClassLoader(url);
    // Get the application's main class name
    String name = null;
    try {
      name = cl.getMainClassName();
    } catch (IOException e) { System.err.println("I/O error while loading JAR file:");    
      System.exit(1); }
    if (name == null) 
      { fatal("Specified jar file does not contain a 'Main-Class'" + " manifest attribute"); }
    // Get arguments for the application
    String[] newArgs = new String[args.length - 1];
    System.arraycopy(args, 1, newArgs, 0, newArgs.length);
    // Invoke application's main class
    try {
      cl.invokeClass(name, newArgs);
    } catch (ClassNotFoundException e) { fatal("Class not found: " + name); } 
      catch (NoSuchMethodException e) { fatal("Class does not define a 'main' method: " + name); }
      catch (InvocationTargetException e) { e.getTargetException().printStackTrace(); System.exit(1); }
  }

  private static void fatal(String s) {
    System.err.println(s);
    System.exit(1);
  }

  private static void usage() {
    fatal("Usage: java JarRunner url [args..]");
  }
}

class JarClassLoader extends URLClassLoader {
  private URL url;
  public JarClassLoader(URL url) {
    super(new URL[] { url });
    this.url = url;
  }

  public String getMainClassName() throws IOException {
    URL u = new URL("jar", "", url + "!/");
    JarURLConnection uc = (JarURLConnection) u.openConnection();
    Attributes attr = uc.getMainAttributes();
    return attr != null ? attr.getValue(Attributes.Name.MAIN_CLASS) : null;
  }

  public void invokeClass(String name, String[] args)
      throws ClassNotFoundException, NoSuchMethodException,
      InvocationTargetException {
    Class c = loadClass(name);
    Method m = c.getMethod("main", new Class[] { args.getClass() });
    m.setAccessible(true);
    int mods = m.getModifiers();
    if (m.getReturnType() != void.class || !Modifier.isStatic(mods)
        || !Modifier.isPublic(mods)) { throw new NoSuchMethodException("main"); }
    try {
      m.invoke(null, new Object[] { args });
    } catch (IllegalAccessException e) { System.out.println("Access denied"); }
  }
}

Compliant Solution

If the program expects the user to manually install the new jar file, the user can explicitly check the signature from the command line. Any malicious tampering will lead to a SecurityException when the jarsigner tool is invoked with the -verify option.

jarsigner -verify signed-updates-jar-file.jar

An explicit signature verification check should be built within the invoking program. This can be achieved by obtaining the chain of certificates from the CodeSource of the class being loaded and checking if any one of the certificates belongs to the trusted signer whose certificate has been obtained securely beforehand and is stored in a local keystore. The invokeClass method can be modified to do this as shown in this compliant solution.

Class c = loadClass(name);
Certificate[] certs = c.getProtectionDomain().getCodeSource().getCertificates();
if(certs == null) {
  System.out.println("No signature!"); return;  // return, do not execute if unsigned
}  

KeyStore ks = KeyStore.getInstance("JKS");
ks.load(new FileInputStream(System.getProperty("user.home"+ File.separator + "keystore.jks")),
  "loadkeystorepassword".toCharArray());
Certificate pubCert = ks.getCertificate("user");  // user is the alias
certs[0].verify(pubCert.getPublicKey()); // check with the trusted public key, else throws exception

It is not always the case that arbitrary code characterized by system damage gets executed. By default, the URLClassLoader and all its subclasses are only given enough permissions to interact with the URL that was specified when the URLClassLoader object was created. This means that one can interact with the specified host by default. This however, does not eliminate the risk since the loaded file may need to be granted appropriate privileges to perform more sensitive operations such as updating an existing local jar file. Code signing gives the receiver the confidence to grant the remote code the requisite permissions.

Risk Assessment

Running unsigned code obtained from both trusted or untrusted locations can lead to execution of arbitrary code supplied by an attacker, given sufficient permissions in the security policy.

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

[[API 06]]
[[Gong 03]] 12.8.3 jarsigner
[[Eclipse 08]] JAR Signing and Signed bundles and protecting against malicious code
[[Halloway 01]]
[[Flanagan 05]] Chapter 24. The java.util.jar Package
[[Oaks 01]] Chapter 12: Digital Signatures, Signed Classes
[[Tutorials 08]] The JarRunner Class, Lesson: API and Tools Use for Secure Code and File Exchanges and Verifying Signed JAR Files
[[JarSpec 08]] Signature Validation
[[Bea 08]]
[[Muchow 01]]
[[MITRE 09]] CWE ID 300 "Channel Accessible by Non-Endpoint (aka 'Man-in-the-Middle')", CWE ID 319 "Cleartext Transmission of Sensitive Information"

SEC04-J. Beware of standard APIs that perform access checks against the immediate caller      00. Security (SEC)      SEC06-J. Assume that all Java clients can be reverse engineered, monitored, and modified