Today the coreruleset project posted a CVE on modsecurity v3.0.4.
The patch to solve this one is in https://gist.githubusercontent.com/crsgists/0e1f6f7f1bd1f239ded64cecee46a11d/raw/181bc852065e9782367f1dc67c96d4d250e73a46/cve-2020-15598.patch.
Created attachment 217952 [details]
ported version of patch
Patch applied and generated with 'make makepatch' afterwards.
(In reply to Felipe Zipitria from comment #1)
Thanks for the patch, it applies and builds fine. Can you let us know where does this patch come from? e.g., upstream commit or bug report.
Just too have it documented: there is some controversy around this patch. Trustwave has disputed the CVE: https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/modsecurity-regular-expressions-and-disputed-cve-2020-15598/
Nginx has applied it and discussed in https://www.nginx.com/blog/addressing-dos-vulnerability-cve-2020-15598-in-modsecurity/.
My take would be to apply it (but I am coreruleset developer).
(In reply to Felipe Zipitria from comment #3)
Thanks for the context, Felipe. When the CRS team made the announcement yesterday I immediately came here to make sure a bug had been filed. This is something I would expect to be addressed in modsecurity itself as it seems like a major regression.
Regardless of the validity of the CVE itself, it does seem the patch has already been applied upstream, though a release hasn't been cut yet: https://github.com/SpiderLabs/ModSecurity/pull/2348. So I would argue this is likely safe to apply to the port. If there is concern about a regression, perhaps it could be hidden behind OPTIONS.
One of the problems was not releasing a 3.0.5 fixing this one.
I think we need to address it. Debian mantainers (and other distros) are applying it also.
And then wait till 3.0.5.
Release this for now, I don't think I have time by the end of this week. Hope others can work on this before I have time on this one again.