ModSecurity could be preventing Basic Authentication coming from mod_jk about modsecurity

[rcbarnett-zz]

Original reporter: ivanr

[rcbarnett-zz]

gunfus: I dissabled mod-security and now mod_jk seems to be working again. I was able to reach the 'manager' application installed in tomcat

[rcbarnett-zz]

ivanr: It would be great if you could perform a couple of more tests, by putting ModSecurity back in but progressively disabling features. The hope is that we would narrow it down to a feature that causes the problem. Here are some ideas:

• Remove all rules
• Disable response body access (SecResponseBody Off)
• Disable request body access (SecRequestBody Off)

If this is a low-traffic installation then please have the debug log at level 9 for the entire time, and attach it here afterwards for developers' access only.

Thanks!

[rcbarnett-zz]

brectanus: Duplicated this on my box. Attached a pcap showing the WWW-Authentication header coming back from tomcat, but not from httpd.

I will start analysing now.

Forgot this last time:

Ubuntu (debian) httpd 2.2.8 + mod_jk 1.2.25 + tomcat 5.5 + ModSecurity 2.5.6 + CRS 1.6.1

[rcbarnett-zz]

brectanus: The WWW-Authentication header is not written to the httpd output if all the following hold true:

1. ModSecurity module is loaded.
2. SecResponseBodyAccess is On.
3. SecResponseBodyMimeType contains text/html

Under the above conditions, ModSecurity reads the response correctly, but never receives an EOS bucket (only a FLUSH) from mod_jk. Because of this, ModSecurity does not see that we completed receiving the response body and phase 4 (RESPONSE_BODY) is not run.

The complete response looks something like this when ModSecurity is looking at it:

HTTP/1.x 401 Unauthorized
Cache-Control: no-cache
Pragma: No-cache
Expires: Wed, 31 Dec 1969 16:00:00 PST
WWW-Authenticate: Basic realm="Tomcat Manager Application"
Content-Length: 948

<title>Apache Tomcat/5.5 - Error report</title><style></style>

HTTP Status 401 -

---

type Status report

message

description This request requires HTTP authentication ().

---

Apache Tomcat/5.5

However, below is what is sent to the client (a compiled in httpd response):

HTTP/1.x 401 Unauthorized
Date: Mon, 08 Sep 2008 21:45:33 GMT
Server: Apache
Content-Length: 381
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

<title>401 Unauthorized</title>

Unauthorized

This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.

Something ModSecurity is doing when adding its output filter is causing httpd to send the default response which does not contain the WWW-Authenticate header.

I modified ModSecurity so that a FLUSH is treated just like an EOS (for testing only). In this case ModSecurity sees the end of the response (ie the FLUSH which seems should be an EOS), phase 4 is run and all is ok (client gets the correct response).

I am not yet sure who is at fault here, but it surrounds this EOS vs FLUSH issue.

As a workaround, disabling response body access (SecResponseBody Off or ctl:responseBodyAccess=off) will prevent the issue, but at the cost of no outbound inspection.

Editied to clean up the extra newlines.

[rcbarnett-zz]

ivanr: WORKAROUND: By the way, we are running this application (JIRA) on a Tomcat behind Apache. We're not experiencing any problems because we deployed with mod_proxy connecting the two. So, in addition to turning response inspection off, sites can switch to mod_proxy instead of mod_jk to work around this issue until it is resolved.

[rcbarnett-zz]

ivanr: My guess is that, because we do not see the EOS bucket, we never send anything through. As far as I am aware response headers are sent just before first data is about to be sent. So Apache is probably seeing the status code (401) but realises there's no content coming and it responds with its default.

[rcbarnett-zz]

brectanus: I sent a note to tomcat-dev mailing list, but no response. I'll probably file a bug to see if that gets further.

http://mail-archives.apache.org/mod_mbox/tomcat-dev/200809.mbox/[email protected]

It seems to be a mod_jk issue, but we at least need a workaround (maybe some way to test that we have received the full response w/o relying on EOS bucket). Assigning this to 2.5.7.

[rcbarnett-zz]

brectanus: Added a patch to work around this issue by interpreting a FLUSH bucket as an EOS if all of the following is true:

1. "jakarta-servlet" is the handler.
2. This is the last bucket, which is a FLUSH.
3. The number of bytes in the C-L header has been received.

I also filed a bug with Apache to see if I can get some clarification from them:

https://issues.apache.org/bugzilla/show_bug.cgi?id=45812

[rcbarnett-zz]

brectanus: The above fix is included in changeset 1205.

[rcbarnett-zz]

brectanus: A fix should be coming into tomcat SVN soon which I will test.

However, even if this is fixed in a later version of mod_jk, perhaps we still need to work around this type of problem. Ivan, do you see any issues with removing the handler check from my patch and making this a more generic workaround (so only 2 and 3 from the requirements above)?

[rcbarnett-zz]

ivanr: I don't think that it's a good idea to have workarounds, in ModSecurity, for problems in other packages.

[rcbarnett-zz]

brectanus: This is a mod_jk bug that is fixed in the SVN version. You will need to patch your version of mod_jk or upgrade when the official fix comes out. In the mean time, you can use one of the suggested workarounds.

[rcbarnett-zz]

gunfus: Thanks for working on this issue guys.

[rcbarnett-zz]

brectanus: The mod_jk issue has been fixed upstream:

http://svn.apache.org/viewvc?view=rev&revision=695816

[fernandohlmaia]

Dear. I still have the same problem. I have a form in php with basic authentication. In the logs, appearance that entered the rule id: 921130. My content is limited, I do not know how to solve. Every help is welcome.