Do we need a completely new rule for this?

Any suggestions on a rule where this might fit into are welcome.

Might be something to discuss in the next meeting. I'll add an item to the list.

Any suggestions on a rule where this might fit into are welcome. I created a new rule to keep things simple, but willing to adapt if decided to.

I just realised that we already try to detect brace expansion in combination with shell RCE:

But the payloads I mentioned are bypassing CRS, maybe because there isn't a rule for it?

Well, the pattern is only detected when the ~ modifier is used for the cmdline processor. I've added , to the anti-evation.unix pattern experimentally: [\x5c'\"\[),]*(?:(?:(?:\|\||&&)\s*)?\$[a-z0-9_@?!#{(*-]*)?\x5c?. With this, I can detect brace expansion of known commands: https://regex101.com/r/8mBQBh/1.

The patterns for the command line processor are defined here: https://github.com/coreruleset/coreruleset/blob/main/regex-assembly/toolchain.yaml.

Only commands that are part of the commands list and are not filtered due to FPs for a given rule will be detected.

7zx is one of the commands from the list and ;{7,z,x} was not detected before the change. To detect ;{,... (leading comma), we need to update the prefix expressions, e.g., in unix-shell-evasion-prefix.ra:

##! ${ifconfig}
\${
##! ${,ifconfig} - brace expansion with leading comma
\${,

We probably also need to extend 932240 to detect brace expansion as part of the generic detection.

Well, we would need to make a couple of changes in any case, at different locations. While it would be consistent, I'm leaning towards a single rule (maybe two at different PLs). The complexity will not do us any good.

Should I add the + character to PL1 or PL2? It's used while specifying options for some commands.

Can you add an example on how to use the +? Then we can decide if it fits PL1 or PL2.

There are only a few commands that use it, e.g. alias(which we are already detecting) and a few other bash/zsh builtins. I think it'll be better suited at PL2.

@Xhoenix Can you add an example on how to use the +?

From bash manpage:

set +abefh...
set +o option-name
pushd +n
popd +n
dirs +n
compopt +o option

Alias in zsh also uses the +.

Thanks for the explanation. I don't see the + usage as critical even if you execute set + I don't see it as something that might end up in an exploitation? But if you can find a good use case, please document it so we add the +.

@fzipi As I wrote in #3780 (comment), I'm leaning more towards a new rule now, because we'd need to make changes in multiple places to get this working with the current RCE rules. Also, the rules are already too complex and adding another detection will only make it harder to maintain this particular detection.

Pong!

Nice. Only the lint errors left.

Thanks @Xhoenix!

@fzipi need your approval.

@fzipi need your approval