Bug 2101020

Description of problem:

The RESPONSE_STATUS rule from RESPONSE-950-DATA-LEAKAGES.conf fails with a larger proxied 500 response or if some smaller response spans packets.  Instead of turning it to a 403, it still returns the backend app 500 and it may also truncate the 500 response.

Version-Release number of selected component (if applicable):

latest


How reproducible:

Always with large 500 response exceeding default 8kb ProxyIOBufferSize


Steps to Reproduce:
1. install httpd, mod_security and mod_security_crs
2. Enable paranoia level 2 

SecAction \
  "id:900000,\
   phase:1,\
   nolog,\
   pass,\
   t:none,\
   setvar:tx.paranoia_level=2"

3. Set up a  simple proxy pass to some local app backend

ProxyPass / http://localhost:8080/

4. Run an app server like Tomcat or JBoss with the reproducer deployed
5. Request http://localhost/reproducer/500.jsp for a large response that gives a 500. Request http://localhost/reproducer/small500.jsp for a control that will work with a 403.  Request http://localhost/reproducersmall500.jsp?length=9000 to break that control case with a larger content length.

Actual results:

500 is returned with a possible incomplete body

Expected results:

Desired 403 is returned instead of backend app 500


Additional info:

This occurs because the rule runs on phase 4 and interjects only after mod_proxy has already started flushing some 500 app response to the client.  Thus, it may block smaller responses that weren't flushed before phase 4 or it truncates 500s that started flushing before phase 4.  The rule needs to block the 500 response in phase 3 instead.  A standalone rule outside the core rule set like this works:

SecRule RESPONSE_STATUS "@rx ^5\d{2}$" \
    "id:950101,\
    phase:3,\
    deny,\
    t:none,\
    msg:'The Application Returned a 500-Level Status Code',\
    logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
    ctl:auditLogParts=+E,\
    severity:'ERROR'"

Adjusting these rules from the core rule set to operate in phase 3 fixes the issue as well:

RESPONSE-959-BLOCKING-EVALUATION.conf:

SecRule TX:PARANOIA_LEVEL "@ge 2" \
    "id:959061,\
    phase:3,\
    pass,\
    t:none,\
    nolog,\
    setvar:'tx.outbound_anomaly_score=+%{tx.outbound_anomaly_score_pl2}'"

SecRule TX:OUTBOUND_ANOMALY_SCORE "@ge %{tx.outbound_anomaly_score_threshold}" \
    "id:959100,\
    phase:3,\
    deny,\
    t:none,\
    msg:'Outbound Anomaly Score Exceeded (Total Score: %{TX.OUTBOUND_ANOMALY_SCORE})',\
    tag:'anomaly-evaluation',\
    ver:'OWASP_CRS/3.3.0',\
    setvar:'tx.anomaly_score=+%{tx.outbound_anomaly_score}'"

RESPONSE-950-DATA-LEAKAGES.conf:

SecRule RESPONSE_STATUS "@rx ^5\d{2}$" \
    "id:950100,\
    phase:3,\
    block,\
    capture,\
    t:none,\
    msg:'The Application Returned a 500-Level Status Code',\
    logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
    tag:'application-multi',\
    tag:'language-multi',\
    tag:'platform-multi',\
    tag:'attack-disclosure',\
    tag:'PCI/6.5.6',\
    tag:'paranoia-level/2',\
    tag:'OWASP_CRS',\
    tag:'capec/1000/152',\
    ctl:auditLogParts=+E,\
    ver:'OWASP_CRS/3.3.0',\
    severity:'ERROR',\
    setvar:'tx.outbound_anomaly_score_pl2=+%{tx.error_anomaly_score}',\
    setvar:'tx.anomaly_score_pl2=+%{tx.error_anomaly_score}'"

But this is a larger overall concern that the core rule set has many rules delegated to phase 4.  Those other rules still depend on the PARANOIA_LEVEL/OUTBOUND_ANOMALY_SCORE rules operating in phase 4 so it's not really proper to move them to phase 3. 

This RESPONSE_STATUS is changed to phase 3 in latest 4.0.0 candidate release core rule set:

https://github.com/coreruleset/coreruleset/blob/v4.0/dev/rules/RESPONSE-959-BLOCKING-EVALUATION.conf#L175

But 4.0.0 still doesn't block in phase 3 here by default without an additional EARLY_BLOCKING setting:

https://github.com/coreruleset/coreruleset/blob/v4.0/dev/rules/RESPONSE-959-BLOCKING-EVALUATION.conf#L175


So it blocks based on the 500 response anomaly score only in phase 4 by default to induce the same issue.  But this quite recent early blocking addition is detailed further here and was first released just a few months ago in a 4.0.0 release candidate:

https://coreruleset.org/20220428/coreruleset-v4-rc1-available/
https://coreruleset.org/20220302/the-case-for-early-blocking/


So I tested with it set for early_blocking like so on the 4.0.0 candidate:

SecAction \
  "id:900120,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.early_blocking=1"

This now enabled the block to be done if needed based on the anomaly score in phase 3 and this corrected the issue as expected on the latest 4.0.0 candidate rule set.


Would we consider updating to 4.0.0+ with early blocking or consider backporting that?  Or implement any other improvement to allow such a RESPONSE_STATUS rule to work in our older core rule set versions?