Problematic word boundary match in 932* rules #3401
Comments
|
@theMiddleBlue Any thoughts on this one? |
|
TBH I'm a bit confused by the original report, that points to 'test=settings' not detected. Is it related to this issue or the point has evolved to something else? Talking about the command in querystring parameter, I'm always of the opinion that we can't protect the application from something like
I know that we are in a scenario in which command is blocked and command2 not. That's ugly and sounds like bypass. But I think I'm not pointing to the right issue here, and I guess I need to understand better what's the problem here 😂 |
|
It's only related because |
|
make sense to me, and it could work. The problem with matching whitespaces when we talk about RCE on bash/dash is always bypassable with |
|
True, that kind of thing should be caught by other rules though right? So |
|
Yes, absolutely! Apologies for the late response! |
Unix commands such as `dig` require options or they won't run. `dig` uses the `@` anti-evasion pattern (e.g., for 932237). For a command such as `dig --help`, the final word boundary (`\b`) in 932237 actually prevents a match. The `@` causes `dig ` to be matched, but the word boundary will not match because both the space character and the dash character are in `\W` (for `\b` to match, one of them would have to be in `\w`). This commit modifies the final word boundary of 932237 to `(?:\b|\W)`, in order to fix this. Note that the final expression must work for commands without options, commands with options (`@`) and for command prefixes (`~`, e.g., `gcc` or `pip`). Fixes coreruleset#3401
Uh oh!
There was an error while loading. Please reload this page.
The 932* rules, such as 932237 for example, use a word boundary match to ensure that "something" follows a command word. At a word boundary, two adjacent tokens must not both match
\wand\W, i.e., one must be a word token and the other must not. This means that "something" must be a word token if the previous token was a space, redirect, etc. If "something" is not a word token, such as the dash character, then the word boundary match will fail.Example:
some-command --helpwould not match a search forsome-command.A possible solution to this problem might be to replace the word boundary match
\bwith\S.This issue was discovered in #3394 by @EsadCetiner.
The text was updated successfully, but these errors were encountered: