mod_jk sends bad packet when method unknown

[Henri Sivonen]

Distribution: Ubuntu 7.04 on x86_64
Package: libapache2-mod-jk 1:1.2.18-3ubuntu1.1

Steps to reproduce:
1) Instantiate Jetty 6.1.7 with this simple Java program:
    public static void main(String[] args) throws Exception {
        Server server = new Server();
        Connector connector = new Ajp13SocketConnector();
        connector.setPort(Integer.parseInt(args[0]));
        server.addConnector(connector);
        server.start();
        System.in.read();
        server.stop();
    }
(You need Jetty, jetty util, jetty ajp and the servlet API in the classpath.)
2) Attach a debugger to Jetty's Ajp13Parser class and set a break point to the line that reads _handler.parsedMethod(Ajp13RequestPacket.getMethod(_buffer));
3) Use mod_jk from Ubuntu 7.04 to make Apache delegate a URI to the Jetty process via AJP13.
4) Telnet to your Apache.
5) Type:
FOO /url-that-is-delegated-to-jetty HTTP/1.1
Host: appropriate-host-name-here

6) Observe the AJP13 packet that Jetty receives from mod_jk.

(I suppose alternatively this could be observed without Jetty using netcat or similar.)

Actual results:
The byte that communicates the HTTP verb has the value 0xFF. This value is not part of the documented protocol:
http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html#method
Moreover, it appears that this isn't a legitimate AJP13 extension, either, because the string "FOO" is not present in the packet.

If you step further in the debugger, Jetty will experience a null pointer, because it trusts that it gets only correct AJP13 packets from a trusted party. (I've reported this to Jetty developers.)

If Jetty is used as part of a larger application, this may put the application is a state that causes the app no longer to work causing denial of service. (I'm seeing this loss of subsequent functionality issue in a big app but I'm unable to produce a minimized test case. Anyway, since this is a real DoS vector for an actual service I maintain, I'm marking this as a security issue.)

It is semi-reasonable for AJP13 recipients to trust that they only get valid packets, because AJP13 is supposed to be used only between trusted parties.

Expected results:
Expected mod_jk to respond with 501 Not Implemented when it receives an HTTP method that it cannot map to a legal AJP13 value.

Additional info:
I expect that this has been fixed upstream--perhaps even in Gutsy, but I am unable to verify.

[Henri Sivonen (hsivonen)]

Attaching a full .java file I used for bootstrapping a minimal AJP13 recipient for attaching a debugger to.

[Henri Sivonen (hsivonen)]

I figured out the last ingredient of the DoS situation: When the mod_jk load balancer is in use, the AJP worker NullPointerException behavior provoked by the malformed packet makes mod_jk think that the worker died and mod_jk won't try the same worker for a while for any request.

So the DoS scenario happens like this:
1) Send unknown method to Apache when mod_jk with load balancing is in use and the AJP worker is Jetty 6.1.7.
2) mod_jk sends a malformed AJP packet to Jetty.
3) Jetty trusts that the AJP packets are legal and fails with a NullPointerException. Jetty doesn't crash and could handle more requests.
4) mod_jk load balancer thinks that the AJP worker went offline.
5) mod_jk load balancer won't forward requests to the worker for a while rendering the service unusable for all users--even for legitimate requests.

[Jamie Strandboge (jdstrand)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. Since the package referred to in this bug is in universe or multiverse, it is community maintained. If you are able, I suggest coordinating with upstream and posting a debdiff for this issue. When a debdiff is available, members of the security team will review it and publish the package. See the following link for more information: https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures