Hardening: Avoid shell-based popen usage in InspectFile operator#3489
Open
praneet390 wants to merge 6 commits intoowasp-modsecurity:v3/masterfrom
Open
Hardening: Avoid shell-based popen usage in InspectFile operator#3489praneet390 wants to merge 6 commits intoowasp-modsecurity:v3/masterfrom
praneet390 wants to merge 6 commits intoowasp-modsecurity:v3/masterfrom
Conversation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR proposes a security hardening improvement to the InspectFile operator external command execution path.
Currently, InspectFile::evaluate constructs a command string and invokes it using popen(), which executes via the system shell.
While current usage paths (e.g., FILES_TMPNAMES) pass engine-generated sanitized filenames and are not attacker-controlled, invoking a shell with concatenated arguments is a fragile pattern and increases risk if future variable sources expand.
This PR starts discussion toward replacing shell-based execution with argument-safe process execution (execve/spawn with explicit argv array), removing shell interpretation from the execution path.
Security benefits:
This PR currently adds a security hardening note and opens discussion on the preferred cross-platform implementation approach for v2 and v3.