All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Exim "21nails" vulnerabilities
Patch up your exim installs today, friends. New vulnerability: https://www.qualys.com/2021/05/04/21nails/21nails.txt
Brief description:
When Exim receives a mail, it creates two files in the "input"
subdirectory of its spool directory: a "data" file, which contains the
body of the mail, and a "header" file, which contains the headers of the
mail and important metadata (the sender and the recipient addresses, for
example). Such a header file consists of lines of text separated by '\n'
characters.
Unfortunately, an unprivileged local attacker can send a mail to a
recipient whose address contains '\n' characters, and can therefore
inject new lines into the spool header file and change Exim's behavior
And that's just the first. There's more in this.
If you're using DirectAdmin on your server, this will patch it and apply one of my sane customizations that I believe every server should have anyway:
https://config.mxroute.com/patch/exim/05052021/05052021exim.sh
Comments
Long live Postfix
Short live Postfix
Recently I dealt with what looked to be an exim exploit. In my case it wasn't as dangerous in function as it was in annoyance. It's entirely possible that one of them is fixed in this, will take me more time to sort through it all though.
The event was very interesting. Someone attempted to open relay through the server and, as far as the logs indicated, they failed as expected. However, despite "failing" and having no logs of success, the outbound relays recorded the servers actually trying to send the emails. They were all blocked thankfully by systems that weren't intended for that specifically but ended up doing the job. They were no longer successful after exim restarts to break the connections, so I never captured it in debug mode. If it happened to others they wouldn't have noticed unless they were capturing the outbound traffic somehow, or their IP was suddenly blacklisted.
On the exim servers it looked like this:
But the outbound filter actually recorded it, which it shouldn't have even received:
I'll know more about if that relates to something in this document later, but it's a worthy side note for anyone looking to see if their systems had been exploited. As far as I'm concerned, that event was an exploit of some kind.
I don't use Exim, just wonder what dose disabling HELO_IS_LOCAL_DOMAIN actually fixes or prevent.
So the user adds “mydomain.com” into DirectAdmin. But they have another server with a hostname “mydomain.com” which connects a web application to the DA server to send mail over SMTP. That server declares its hostname on connection to the DA server, it says “hi, I’m mydomain.com.” The DA server replies “the hell you are, that’s my domain, fuck off.”
But it wasn’t an attacker. It was just a guy who has his domain as his server hostname, and also has the domain added to DirectAdmin. And since there’s no exploit in simply declaring your EHLO/HELO to be the name of a domain listed in /etc/virtual, nor a common attack that does it just for kicks, this proves merely to be a hurdle with no purpose other than to make people stop using their root domain as a hostname (and good luck with that).
Support ticket generator at best.
After going over the document my conclusion wasn't particularly interesting on this note. I'm going with "maybe." There are certainly some vulnerabilities documented here that seem to have a high probability of allowing a number of activities that could perhaps pave the way for the event that I noticed. What is unknown to me is exactly what it would look like in the logs, whether or not what I would see at the time is a match for one of those exploits. In the absence of debug data during the event (since it never continued after restarting into debug mode), I believe that a full answer is presently unknowable within reasonable boundaries.
The reasonable boundaries being the time investment. Given that this many vulnerabilities were just patched, and the nature of my unique situation to catch future occurrences of what was documented in that event, there is not enough value to the time that would be required to reach a more definite conclusion. Will return here to close the loop to any interested reader should that change.
Qualys team discovered sudo vulnerability this year which is from 2011. Now exim. What's next for these Sherlock Holmes? They are having a "great" year.
Thanks @jar
Updated my exim's to 4.94.2
If I only use exim as a local relay (local -> exim -> mailserver), am I fine?
Aye someone is going to have to communicate with exim to exploit any of these, if they can’t then no harm.
I stopped using Exim ages ago. I use either Postfix or OpenSMTPD, though I'm not running a major email provider or anything. Just relaying from home or emailing my gmail from servers where things go wrong.
Is there some reason to run Exim? I know cPanel used it the last time I looked at cP...which is probably a strike against it.
It’s really a pretty great, flexible MTA. But having it bundled with cPanel/DA is a big. If you’re using one of those, the hoops you’d jump through to replace it would be equivalent to rebuilding the panels.
Newline injection is such a basic vulnerability... I'm surprised this wasn't found sooner. Or maybe it was and this has been exploited for a while...
It's the default MTA bundled with Debian for whatever reason, which I imagine is responsible for some nontrivial percentage of Exim usage (a looooot of people just stick to the defaults)
Exim is conceptually a descendant of Sendmail, and Sendmail was once ubiquitous in the free software world
it's quite fun to read their debate long time ago
https://wiki.debian.org/Debate/DefaultMTA
for the same reason (smaller footprints), decided to use exim on my custom linux. as long as still very actively maintained, there is no rush to switch.