mod_security 2.9.2 appears to truncate POST bodies when using mod_proxy_ajp and mod_jk when using ProcessPartial

[markblackman]

We configure our POST body limit as follows

  <IfModule mod_security2.c>
    SecRuleEngine DetectionOnly

    SecRequestBodyAccess On
    SecRequestBodyLimitAction ProcessPartial

    SecRequestBodyNoFilesLimit 4096
    SecRequestBodyLimit 4096
    SecRequestBodyInMemoryLimit 4096
  </IfModule>

We can then see on the backend that the resulting request is truncated to the SecRequestBodyLimit 4096

[zimmerle]

Hi @markblackman,

The configuration SecRequestBodyLimit limits the amount of bytes of the request body to be inspected. That in the expected behavior.

[markblackman]

Thanks. Sorry, if it wasn't clear. I am not referring to the inspection behaviour. I am referring to the proxying behaviours. I can completely live with only inspecting 4k bytes out of 8k bytes in an HTTP body and that's what I expect from ProcessPartial. What I can not live with and do not expect, is the 8K body getting truncated to 4k when it's passed to the backend Tomcat servers. Is this well known or well documented behaviour, truncating after inspection?

[markblackman]

To be even clearer, with ProcessPartial I expect the entire body to be proxied regardless of how much is inspected. Is this expectation misplaced?

[zimmerle]

What is the version of your ModSecurity?

[markblackman]

[Mon Jul 02 17:51:54.562328 2018] [:notice] [pid 2380366:tid 140467527632640] ModSecurity for Apache/2.9.2 (http://www.modsecurity.org/) configured.

[zimmerle]

Is there any version mismatch in the dependencies?

[markblackman]

None that are flagged by modsecurity itself.

[Mon Jul 02 18:22:44.359483 2018] [:notice] [pid 2463776:tid 140163929712384] ModSecurity for Apache/2.9.2 (http://www.modsecurity.org/) configured.
[Mon Jul 02 18:22:44.359495 2018] [:notice] [pid 2463776:tid 140163929712384] ModSecurity: APR compiled version="1.6.3"; loaded version="1.6.3"
[Mon Jul 02 18:22:44.359502 2018] [:notice] [pid 2463776:tid 140163929712384] ModSecurity: PCRE compiled version="8.41 "; loaded version="8.41 2017-07-05"
[Mon Jul 02 18:22:44.359506 2018] [:notice] [pid 2463776:tid 140163929712384] ModSecurity: YAJL compiled version="2.1.0"
[Mon Jul 02 18:22:44.359511 2018] [:notice] [pid 2463776:tid 140163929712384] ModSecurity: LIBXML compiled version="2.9.7"
[Mon Jul 02 18:22:44.359515 2018] [:notice] [pid 2463776:tid 140163929712384] ModSecurity: Status engine is currently disabled, enable it by set SecStatusEngine to On.

[markblackman]

If there is some debugging to enable, we can do that.

[markblackman]

And just as a quick reminder, this only happens in the context of the following proxy modules.

• Oracle Weblogic (mod_wl)
• mod_jk (AJP)
• mod_proxy_ajp (AJP)

However, it works fine in the context of the standard HTTP proxy module

• mod_proxy_http and mod_proxy_https

I can imagine that Oracle would not play nicely with the Apache bucket brigade, but I assume mod_security does as well as mod_jk and mod_proxy_ajp.

[zimmerle]

Any position from the Oracle Weblogic module?

[zimmerle]

It is likely that ModSecurity is being called after the mod_wl. Therefore not being able to manipulate the request.

[markblackman]

That's possible, but how does that explain the mod_jk and mod_proxy_ajp behaviours?

[markblackman]

We still see this issue with mod_proxy_ajp and Tomcat backends. We'll provide more details of a reproducible setup with a RH7 environment. I would be grateful if you could consider trying to reproduce what we see. In summary, ignoring the weblogic problem, mod_proxy_ajp configurations exhibit this behaviour, but mod_proxy_http configurations do not.

[markblackman]

As a further data point, this issue only occurs with with Content-type: multipart/form-data although typically, this is what you would use for bigger bodies anyway.

[markblackman]

For the moment, we have addressed our issue by making this change

From

SecRequestBodyNoFilesLimit 4096
SecRequestBodyLimit 4096
SecRequestBodyInMemoryLimit 4096

To

SecRequestBodyNoFilesLimit 8192
SecRequestBodyLimit 2147483646
SecRequestBodyInMemoryLimit 8192

For us, it is extremely counter-intuitive for modsecurity to permanently and irretrievably throw away body content after SecRequestBodyLimit. It should simply ignore the extra content, not throw it away, so that further filters can't see/pass the extra content.

Is that body content discard really the designed/documented/desired behaviour?

[markblackman]

In other words, always buffer the entire request, but only process up to the point requested. Other filters may need that body. Buffering and processing are two very logically separate processes. Any generic body truncation should only be handled by core Apache directives.

[markblackman]

Despite these changes, we're still seeing problems with body content being discarded by modsecurity on a POST. In a case observed yesterday, modsecurity claimed a body size of 16315

'[30/Jan/2019:14:42:30 +0000] [server1.some.domain.com/sid#a72c368][rid#e1ac640][/dat/restservice/admin/userProvision][4] Input filter: Completed receiving request body (length 16315).'

yet a following filter believed the POST body was was 22318 bytes

2019-01-30T14:42:30.4484+00:00 <390948215488593502> Going to get the post data of size=22318 clength=0

Why are mod_security and another input filter disagreeing about the body size?

[zimmerle]

Fixed at #2092.