chore: Add blog post about recently published CVE

content/blog/2024-10-11-cve-2024-46292.md

@@ -0,0 +1,37 @@
+---
+title: 'About CVE-2024-46292 - 2024 October'
+date: '2024-10-11T14:00:00+02:00'
+author: airween
+---
+
+We would like to share our take on the [CVE-2024-46292](https://www.cve.org/CVERecord?id=CVE-2024-46292), which was published on October 9 2024.
+
+<!--more-->
+
+On September 12 we received an email to [email protected] from [@yoloflz101](https://github.com/yoloflz101). The subject was "Modsecurity 3.0.12 Dos Issue". The following is a summary of the exchange with the person who reported the CVE:
+
+* 12:27 CEST: The sender shared with us only the link which also exists in CVE.
+* 14:00 CEST: We tried to clarify several details with reporter via email
+* 16:36 CEST: The reporter responded briefly. They wrote that they were able to attack the ModSecurity engine with a DoS attack. The attack was claimed to be successful against ModSecurity 3.0.12 and CRS 4.1, but not against CRS 3.2 or any version of CRS when attacking ModSecurity 3.0.4.
+* 17:14 CEST: In our response we drew their attention to the fact that if the phenomenon occured only with a certain version of the rule, then the engine probably was not affected; even if they were unable to reproduce the behavior with a very old version of the engine, with both rule versions.
+
+We also informed the reporter that the presented attack is only possible if the value of the variable `SecRequestBodyNoFilesLimit` is set to an extremely high value, significantly higher than the value found in the [recommended configuration](https://github.com/owasp-modsecurity/ModSecurity/blob/5f44383236b94ef8066529861d0b4d603f9b3bcb/modsecurity.conf-recommended#L46). Using values outside of the recommended ranges is the responsibility of users.
+
+While the CVE and the reporters original email both mention ModSecurity 3.0.12, version [3.0.13](https://github.com/owasp-modsecurity/ModSecurity/releases/tag/v3.0.13) had been released almost two weeks before, on September 3.
+
+Despite repeated attempts, we have been unable to reproduce the behavior described by the reporter using the configuration and request as presented on their GitHub page (linked in the CVE).
+
+At this point, the conversation with the reporter ended. As you can see, we have tried to respond to emails as soon as possible.
+
+On October 9 the CVE was published. We immediately contacted the reporter and asked more information:
+
+* why did they not inform us about the publication of the CVE?
+  * they responded that they had opened the CVE before informing us and wrote that they _"didn't expect it to pass."_ and _"only remembered to contact you after submitting."_
+  * **note**: the CVE was recorded on **Septeber 11** - see [mitre.org](https://cve.mitre.org/cgi-bin/cvename.cgi?name=2024-46292) page
+  * they also added that they _"did not continue to verify it due to busy work"_, and that they are _"not very familiar with the specific reasons"_.
+* they never mentioned "buffer overflow" at all in any of our exchanges, so why does the CVE contain that wording?
+  * they responded that they did not know how that wording became part of their CVE submission
+
+We strive to cover every security report as professionally as possible and believe that we have done so in this case. We can only appeal to reporters to be thorough in their reports and to contact us about their intentions to submit CVE's _before_ submitting, only then do we have a fair chance of verifying whether a report warrants a CVE.
+
+Unfortunately, we are still unable to reproduce the issue. If the reporter is unable to provide a proof of concept that is repeatable within next three days we will initiate the procedure for retracting the CVE.