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
@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
@falken @neilmadden @cR0w the current maintainer has closed the report as invalid and shared the writeup
https://github.com/fail2ban/fail2ban/issues/4110#issuecomment-3601428764
https://gist.github.com/sebres/acaa74b1feef034016bb5aca4abf92ab
the conclusion seems to be that there is no vulnerability
@gnyman @falken @neilmadden I'm glad they got it sorted but if it was real, it would have been pretty cool. And I see the CVE is now listed as disputed.
@gnyman @neilmadden @cR0w this is bonkers. I don't understand how AI slop can be used to get a real CVE. Who issued it? On what evidence?
@falken @gnyman @neilmadden MITRE was the CNA and they haven't been doing much vetting of the submissions for a while. At least not on initial publication.
@gnyman @neilmadden @cR0w my server is older than 5 years too. But it's on the Internet so I patch that shit.
yes patching is required and esm provides security patches
@falken @neilmadden Without a CVE most orgs would never even see it. It's a way of tracking them. And there is a lot of known vulnerable stuff out there that hasn't been popped yet. Writing off those not on the bleeding edge will leave no one left.
More importantly, it's a neat vuln. I enjoyed reading about it and any time I see a new vuln like that, I learn something.