|
|
|
|
| |
| Due to a programming flaw in the Java JVM code it is possible to force an unhandled exception on a Java application if the application is tricked into performing many DNS queries. The result is the immediate crashing of the Java application. |
| |
Credit:
The information has been provided by Kurt Huwig.
|
| |
Vulnerable Systems:
* Java Virtual Machine version 1.4.x, 1.5.0
Java uses an 'InitialDirContext' to perform DNS lookups. A wrap-around of an internal variable renders the context unusable after 32768 requests for the next 32768 requests. A remote attacker might trick an application into performing a lot of DNS requests which renders the application unusable. It might also be the cause of some problems with long running server processes.
After 32768 such DNS requests are done without creating a new InitialDirContext, Java will issue the following exception:
javax.naming.CommunicationException: DNS error: ID doesn't match;
remaining name 'sun.com'
at com.sun.jndi.dns.DnsClient.checkHeader(DnsClient.java:426)
at com.sun.jndi.dns.DnsClient.query(DnsClient.java:162)
at com.sun.jndi.dns.Resolver.query(Resolver.java:63)
at com.sun.jndi.dns.DnsContext.c_getAttributes(DnsContext.java:410)
at
com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:213)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:121)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:109)
at
javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:121)
at DNSLookupBug.main(DNSLookupBug.java:17)
In com/sun/jndi/dns/DnsClient.java, 'xid' is of type 'int' but initialized by the 'short' 'ident'. Thus if 'ident' reaches 32768, it becomes negative, rendering 'xid' negative to '-32768':
private short ident = 0; // used to set the msg ID field
[...]
int xid;
synchronized (identLock) {
xid = ++ident;
}
In the class com/sun/jndi/dns/Header.java, the answer from the DNS server is converted backwards but to an 'int' instead of a 'short':
private static int getShort(byte[] msg, int pos) {
return (((msg[pos] & 0xFF) << 8) |
(msg[pos + 1] & 0xFF));
}
The result of this method gives '32768' which is not equal to '-32768' and therefore the failure. A possible fix would be to replace in com/sun/jndi/dns/Header.java:
xid = getShort(msg, pos);
with
xid = (short) getShort(msg, pos);
Workaround
An application must be written in such a manner as to instantiate a new instance of 'InitialDirContext' before the limit of 32768 request is reached. Another solution would be to subclass InitialDirContext and let 'xid' have only positive values.
Proof Of Concept
import java.util.*;
import javax.naming.directory.*;
public class DNSLookupBug {
public static void main(String[] args) {
try {
final Hashtable env = new Hashtable();
env.put("java.naming.factory.initial",
"com.sun.jndi.dns.DnsContextFactory");
DirContext dnsContext = new InitialDirContext(env);
final String[] domain = new String[] {"A"};
for (int i = 0; i < 0xffff; i++) {
dnsContext.getAttributes("sun.com", domain);
if (i % 1000 == 0) {
// use this as a workaround
//dnsContext = new InitialDirContext(env);
System.out.println(i);
}
}
} catch (Exception e) {
e.printStackTrace();
}
}
}
|
|
|
|
|
|
|
|
|
|
