Page History

If a user encounters signed code, chances are that the code requires more than appropriate privileges to carry out its operations. It is in the interest of the users to verify the authenticity and integrity of the artifacts that they wish to deploy. Although it is usually a bad idea to sign code, some actions necessitate this step. For example, if the application needs to establish an http connection with an external host to download plugins or extensions, a vendor may provide signed code instead of having the user deal with complex security policies. Sometimes the policies themselves reflect that only the code signed by the provider should execute with the granted privileges. Since Because executing signed code can be extremely dangerous, verifying authenticity of origin is of utmost importance. Users are most often not the best judges of what code is safe to execute and what constitutes malicious code. Therefore, it is necessary to programmatically verify signed code in the absence of a default security manager mechanism.

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 JAR files are the preferred distribution mechanism. The point and click installation provided by Java Web Start also relies on the jar JAR file format for packaging. Vendors sign their jar JAR files when required, however, this should not be interpreted to be the case that the code cannot be misused.

According to the Java Tutorials\[[Tutorials 08|AA. Java References#Tutorials 08]\]:

...

Depending on how the client code works, signatures may or may not be automatically checked programatically. For instance, any instances of URLClassLoader and its subclasses and java.util.jar automatically verify a signature whenever the jar JAR file appears to be is 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 jarJAR. The legit jar JAR file may be replaced with a malicious jar JAR file containing a different public key and hash values.

This noncompliant code example demonstrates the JarRunner application [Tutorials 08] that can be used to dynamically execute a particular class residing within a jar JAR file [Tutorials 08]. 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.

...

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

...

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 the program can interact with the specified host by default. This howeverHowever, this does not eliminate mitigate the risk since completely as the loaded file may need to be granted appropriate privileges to perform more sensitive operations such as updating an existing local jar JAR file.

Risk Assessment

Running unsigned code obtained from both trusted or untrusted locations can Not verifying the digital signature either manually or programmatically may lead to execution of arbitrary code supplied by an attacker, given sufficient permissions in the security policymalicious code.

...