ModSecurity2 blocks Potential Obfuscated Javascript in outbound anomaly

[becki]

hello there ;)

since the 4.4.1 update mod_security reports a potential obfuscated javascript in outbound and blocks wordpress

i'm using OWASP_CRS/2.2.9 and mod_security rule triggering this is ID 981004 and it reports the following:

Rule Message: Potential Obfuscated Javascript in Output - Excessive fromCharCode
Event: Pattern match "(?i)(String\\.fromCharCode\\(.*?){4,}" at RESPONSE_BODY
Data: Matched Data: String.fromCharCode(55356,56806,55356,56826),0,0),d.toDataURL().length>3e3):\x22diversity\x22===a?(e.fillText(String.fromCharCode(55356,57221),0,0),c=e.getImageData(16,16,1,1).data.toString(),e.fillText(String.fromCharCode(55356,57221,55356,5
Tag: OWASP_CRS/MALICIOUS_CODEbugtraq,13544

Rule Message: Outbound Anomaly Score Exceeded (score 4): The application is not available
Event: Operator GE matched 4 at TX:outbound_anomaly_score 

mod_security regex is matched in the _wpemojiSettings / function and finally resulting in mod_security blocking wordpress ;(

[dd32]

This is caused by [36161] / #33592.

I'm not sure we should do anything to avoid this, that mod_security rule is really restrictive..

What's causing this, is that the file wp-emoji-loader.js contains 5 occurrences of String.fromCharCode( and mod_security only allows 3 instances.
In 4.4.0 we only had 3 instances of that function call.

One reason I say that mod_security rule is crazy, is because we can avoid it simply by doing z=String.fromCharCode; and calling z() instead, completely bypassing it.. and any JS can do the same (I'm actually surprised our minification process didn't do that automatically)

[Clorith]

I don't think we need to touch this, the vendor has already acknowledged the false positive and stated they will fix it.

Of course it's up to hosts to apply the fixed rules, but it's still a silly rule.

[Clorith]

Upstream reports for mod_security it self
​https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/274

Comodo also confirming they will fix the false positive in their 3rd party rules
​https://forums.comodo.com/free-modsecurity-rules-comodo-web-application-firewall/falsepositive-report-thread-t104373.0.html;msg826970#msg826970

[kraftbj]

If there's something we can do on our end to pass the existing rule that is relatively cheap, we should do that. In my experience, hosts are often *very* slow at updating rules, or do so only after being prodded from an user experiencing the issue and then, often, only as a one-off exception.

[Clorith]

I've not got the shared host experience here, so I'll bow to @kraftbj and his wisdom :)

The approach mentioned by @dd32 would probably be a viable solution for 4.4.2 to mitigate the issue, especially now that it turns out there's two vendors offering this same rule, indicating we might see more vendors pick it up as well.

[dd32]

I think this patch works.. it doesn't throw a JS error at least :)

[dd32]

In 36359:

Emoji: Work around a mod_security rule which prevents pages with 4 or more instances of String.fromCharCode( from being served.

Fixes #35412 for trunk.

[dd32]

Opening for 4.4.2

[dd32]

In 36410:

Emoji: Work around a mod_security rule which prevents pages with 4 or more instances of String.fromCharCode( from being served.

Merges [36359] to the 4.4 branch.
Fixes #35412.