Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: revised initial version of CVE response #3

Merged
merged 1 commit into from
Oct 11, 2024
Merged

chore: revised initial version of CVE response #3

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 16 additions & 17 deletions content/blog/2024-10-11-cve-2024-46292.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,32 +4,31 @@ date: '2024-10-11T14:00:00+02:00'
author: airween
---

We would like to share information about the published CVE with id CVE-2024-46292.
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 modsecurity@owasp.org. The subject was "Modsecurity 3.0.12 Dos Issue". Here are some brief summary about our conversation:
On September 12 we received an email to modsecurity@owasp.org. 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 some questionable details and asked the reporter in email
* 16:36 CEST: The reporter answered briefly. He wrote that he was able to DoS the engine with version 3.0.12 and CRS 4.1, but was not able with CRS 3.2. He also mentioned that with ModSecurity 3.0.4 he wasn't reproduce the behavior at all (neither with CRS 4.1 nor 3.2)
* 17:14 CEST: In our response we draw his attention to the fact that if the phenomenon occurs only with a certain version of the rule, then the engine is probably not affected; even if he can't reproduce the behavior with a very old version of the engine, with both rule versions
* 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 must add the fact that on September 12 he mentioned ModSecurity 3.0.12, but the version [3.0.13](https://github.com/owasp-modsecurity/ModSecurity/releases/tag/v3.0.13) was released almost two weeks before, on September 03.
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.

We also informed him that the presented attack is only possible if he increases the variable `SecRequestBodyNoFilesLimit` to an extremely high value. In this case, we assume that everyone knows what they are doing and what risks do they take.
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 the modified configuration, we still cannot reproduce the described behavior. Obviously we used the same parameters and versions.
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).

Then on October 09 the CVE was published. We immediately contacted him and asked more information:
On October 9 the CVE was published. We immediately contacted the reporter and asked more information:

* why did he not inform us about the publication of the CVE?
* he answered that he opened the CVE before he asked us and wrote that he _"didn't expect it to pass."_ and he _"only remembered to contact you after submitting."_
* he also added for the DoS issue that he _"did not continue to verify it due to busy work"_, and he is _"not very familiar with the specific reasons"_.
* he didn't mention "buffer overflow" at all in our conversation
* we asked him about this and he replied he does not know how did it get there (?)
* 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."_
* 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 are still very happy with every announcement and we are happy to cooperate with anyone, but it would be great if anyone who wants to help to discover a bug, contact with us first. An amazing amount of time has passed to deal with this case.

Unfortunately we are still not able to reproduce the issue. If the reporter is unable to provide a satisfactory explanation of the essence of the notification, we will start the procedure to withdraw the CVE.
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 <???> we will initiate the procedure for retracting the CVE.