Neat vuln in Fail2Ban.

https://gist.github.com/R-Security/1c707a08f9c7f9a91d9d84b5010aaed2

Fail2Ban 0.11.2 contains a vulnerability that allows an attacker with the ability to influence logged input (e.g., authentication logs, service logs processed by Fail2Ban filters) to inject specially crafted patterns that lead to command execution within the Fail2Ban action processing pipeline.

Because Fail2Ban actions typically run with root privileges, this can result in privilege escalation, allowing an attacker to execute commands with elevated permissions.

The issue arises from insufficient sanitization of variables passed into action scripts under certain configurations, allowing malicious input to propagate into shell execution.

@cR0w c’mon, why isn’t this called fail2shell with a snazzy website?

@neilmadden @cR0w because anyone running a 5 year old fail2ban install has already been owned by something else. It's barely worth a CVE. I have no idea why these are issued for non-supported versions.

@falken @neilmadden @cR0w happy to bet you something that my five year old server has not been owned by this or something else

There is value in stability as long as there are patches.

And Ubuntu provides free security updates for personal servers through their ESM program.

@falken @neilmadden @cR0w either way as I'm reading and understanding this I don't see why this would affect only old versions

Matches still exists and seems to be passed directly to what looks like a shell in two of the default actions, abuseipdb and blocklist_de

Maybe I'm missing something...

@falken @neilmadden @cR0w yeah ok there are changes meant to ensure untrusted input is passed as arguments not inline so maybe that fixed it

@falken @neilmadden @cR0w so the maintainer of fail2ban responded saying there is not problem that he can see from the report, and then the reporter reiterated that this is indeed a exploitable problem, and he offered to share proof of vuln so I guess we will see where this ends up, until we know I paused my supposedly vulnerable fail2ban instance, it was anyways a recent addition in order to see if reporting IP's to abuseipdb would make them stop faster than just banning them

https://github.com/fail2ban/fail2ban/issues/4110

@falken @neilmadden @cR0w also, just putting it out here, the follow up comment on GH by the reporter does tingle my LLM sense

which might not mean anything, but I have personally been very deep down a rabbit hole of a LLM finding a vulnerability which I totally also believed was a vulnerability

in the end it was not because of how a protocol worked, but I spent an afternoon trying to write a exploit for it

so either way if a llm was involved or not it will be interesting to see how this turns out