Remove possiblity to disable early-blocking processing

[arminabf]

The compile-time option --disable-request-early in ModSecurity 2.x can lead to incorrect request processing with Core Rule Set (CRS) 4.0 and higher (as highlighted here).

Given that CRS 4.0+ relies on functionalities tied to early request processing, disabling it at build time effectively renders these newer CRS versions incompatible and can leave systems non-functional or even vulnerable. To ensure proper functionality and security when using modern CRS versions, I strongly recommend removing the --disable-request-early compile option from ModSecurity 2.x.

[airween]

Hi @arminabf,

thanks for bringing this up.

I see your points and your arguments, and those can be valid.

I would like to discuss this decision with the community, so I leave this issue open - hope that many user will comment their demands and opinions. I'm sure not every user use CRS, and it wouldn't be correct to remove if they need this feature.

But thanks anyway.

[theseion]

I'm curious as to why this option exists at all in ModSecurity, and even more curious as to why you've decided to use the flag @arminabf.

A quick glance at the source code suggests that phase 1 should still run with early processing disabled, just at the start of the "phase 2 hook" instead of the "phase 1 hook". @airween is that a bug?

Unfortunately, there's no way for rules to detect whether that compile time flag was set (at least, I'm not aware of any). Also, removing the flag will not fix the issue with current or older versions of ModSecurity. From the excellent analysis it looks like it should be simple to fix the problem by checking in phase 3 whether the variables are set and initialising them there if they haven't been. This should work for both cases, whether the flag was set or it's a bug in ModSecurity.

[airween]

@airween is that a bug?

I have to check that - both the source code and the behavior.

Btw I just looked at the original post again and I'm also wondering why we need to remove something that is optional and the user has to specifically disable it.

[arminabf]

(sry, was closed unintentionally.. pls re-open it)

[arminabf]

I'm curious as to why this option exists at all in ModSecurity, and even more curious as to why you've decided to use the flag @arminabf.

@theseion, it looks like the option has been introduced with v2.7.0, at that time with experimental background... I think that was the reason for the decision, many years ago...

[airween]

@arminabf,

it looks like the option has been introduced with v2.7.0, at that time with experimental background... I think that was the reason for the decision, many years ago...

but what do you expect with the removing this feature? What will solve that?

[arminabf]

but what do you expect with the removing this feature? What will solve that?

firstly, the recommendation to simply remove the option may not be far-reaching enough (e.g. users of CRS <v4 are not affected), and there may be more comprehensive approaches (e.g. adding a check in CRS >v4, as suggested by @theseion)...

... BUT basically the question is how to prevent someone else from encountering this problem and potentially being confronted with false positives and long-running analysis

but if it doesn't seem necessary to do anything in this context, then the problem has at least been stated hereby and may help someone else... good for me too.

[airween]

@arminabf,

I see your argument, but I'm afraid the mentioned issue does not justify removing that feature.

You are thinking in CRS, and especially in CRS 4. But what if someone uses some different rule set? What is someone uses older CRS?

... BUT basically the question is how to prevent someone else from encountering this coreruleset/coreruleset#3696 (comment)

I think that would be a huge help to add this notice to CRS documentation.
Here is the repository, feel free to send a PR. I can imagine this could be part of installing section.

[theseion]

Putting this one on the agenda.