Skip to content

Conversation

@michaelgranzow-avi
Copy link
Contributor

Currently, it is possible to specify 'block' as the default disruptive
action for any phase. If there is a rule for a phase with default
action 'block' which in turn uses 'block' as its disruptive action,
i.e., wants to use the default disruptive action, and the rule gets
triggered, libmodsecurity enters an infinite recursion with subsequent
segmentation violation.

Include a regression test for this scenario.

Currently, it is possible to specify 'block' as the default disruptive
action for any phase. If there is a rule for a phase with default
action 'block' which in turn uses 'block' as its disruptive action,
i.e., wants to use the default disruptive action, and the rule gets
triggered, libmodsecurity enters an infinite recursion with subsequent
segmentation violation.

Include a regression test for this scenario.
@zimmerle zimmerle self-assigned this Feb 28, 2018
zimmerle pushed a commit that referenced this pull request Feb 28, 2018
@zimmerle
Copy link
Contributor

Hi @michaelgranzow-avi,

Thank you for the patch. Indeed the segfault is not welcomed. However, we still need to have the block working in the same fashion that we had on v2. Therefore, I have proposed a different fix. Available here: 6842d4b

@zimmerle zimmerle closed this Feb 28, 2018
@zimmerle zimmerle added the 3.x Related to ModSecurity version 3.x label Feb 28, 2018
@zimmerle zimmerle added this to the v3.0.1 milestone Feb 28, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

3.x Related to ModSecurity version 3.x

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants