Your title gives Linux sysadmins and fanboyz a bad name. Where is Microsoft even relevant to this article?
Methinks your prejudice has gotten the better of you.
Exim maintainers have warned of an in-the-wild attack that allowed the miscreants to execute malicious code with unfettered system privileges by exploiting a bug in older versions of the open-source mail transfer agent. The memory-corruption vulnerability resides in Exim 4.69 and earlier versions, and already has been used in …
I have just patched 25 servers yesterday, I believe (but I have not tested it) that if you cannot patch Exim itself, you can try to avoid being vulnerable by using these 3 settings:
smtp_banner="something ESMTP server ready"
smtp_accept_max_per_connection = 1
The idea is:
- do not log rejected email headers (AFAIK, this is part of the buffer overflow)
- do not announce yourself as Exim, maybe script kiddies will skip you.
- do not accept more tha one email per connection, as this is part of the attack too. (The attacker overwrites ACL tables memory with the first enormous mail, then sends a second email on the same connection, having your code executed. If he cannot send a second email in the same connection, the attack should fail)
I HAVE NOT TESTED THESE SETTINGS!
Read it again. The OP has patched up 25 servers to the latest version of Exim that lacks the vuln.
He then goes on to say that if, for whatever reason, you cannot upgrade then these settings are supposed to mitigate the problem. But he hasn't done that and cannot confirm that there aren't any nasty side-effects in doing this.
Wonderful sensationalist article. Is this the water in the Silly Valley I wonder which makes the otherwise respectable and properly cynical El Reg behave like the Daily Fail...
Anyway... to the point...
Standard install by most distributions uses a special user for exim instead of root. Not that this is much better anyway as there is a long list of privilege elevation exploits to apply once this has happened. In any case, it is definitely not "root direct" for most systems.
Additionally, the exploit works when the header of a specially crafted message is logged. So sites using greylisting, custom log settings, etc will need some extra effort to exploit. The attacker will have to write a proper "multiple attempts" attack suite which passes all early greylisting and command based antispam checks as these are executed before header is parsed and logged.
On the negative side, if I understand the exploit correctly the main exim daemon will remain alive and you get the shell out of the child processing the message. So monitoring of exim/smtp functionality will not tell give you any information.
As far as "being overlooked" that is a fair point. The exploit belongs to a big class of logging exploits which were all the fashion around 2005. Most of the Internet infrastructure software had a couple of those at that time. Other software did an audit and rewrote most of the logging (example - Pound). Looks like Exim failed on this one. None the less, a couple of exploits in 10 years is a fairly good track record for exim especially when compared to stuff like sendmail, bind or the like.
Oh, and it will be nice if the article is less sensationalist next time. Me coat, the one with the ragged copy of the exim operations manual with notes and additions dating back 11 years now.
Sendmail works now. There was a considerable period when most people running SMTP for a living would have contested that opinion. That is why we have qmail, postgres and exim in the first place.
On top of that, there are a lot of jokes about why is that bat on the Sendmail O'Raily books you know... Mostly centered around how the sysadmin feels after writing a couple of rulesets in M4.
Also, sendmail has suffered from the same bug as the second exim CVE more than once (the local one - custom config).
You've got to be kidding. For years the single most notoriously insecure, over-engineered Linux daemon on the market? Maybe it's better now, but I'd rather slam my cock in a door than waste any more of my life trying to configure that POS.
If a piece of software requires a 400 page book and you learning a new macro language in order to configure it, it's too complex. M4 - jesus, it makes OO Perl look like plain english.
You don't just update server software in a production environment because a new version came along. Not if you want a stable service, that is. Also I'd consider not upgrading a mail server for two years well within the life expectancy of a project to deliver a mail system. In fact if my company delivered new mail servers (or something similar) and they had to be upgraded after two years, there would be serious questions asked about the suitability of the software chosen.
First it was one dev with some very idiosyncratic coding/implementation practices, and now a bunch of maintainers who release something once a decade, if you're lucky.
I personally think it's a maintainability nightmare, and wouldn't touch it with a bargepole.
I'll stick with Postfix, thanks. Designed from the ground-up to be secure - you simply can't install it in an insecure manner, and it requires quite a bit of work to get it sufficiently b0rked to be a security risk as an MTA, unlike Exim and Sendmail, where you have to work to lock things down (although I believe Sendmail is ~slightly~ improved these days, if you ignore that horrible M4).
AC says "You don't just update server software in a production environment because a new version came along."
I know that "received wisdom" is to look at problems you have, only update if the update address an issue you've seen, or if you believe yourself to be vulnerable to a security issue the update corrects. Other than that, leave "production" systems alone.
I don't run like that. Never will. Argue with me if you like, but I've been on exim 4.71 for ages, went to 4.72 soon after it came out. So, with a smug grin, I know I'm in the clear.
My strategy is - ALWAYS update. Life's too short to plough through every issue, see if a particular update addresses it. And are you really, really, really sure every change has been logged in sufficient detail for you to know exactly what issues are corrected ??
Keep the ability to roll back if anything breaks, but keep updated. It's not the ass-covering approach, but it is the professional approach.
YMMV, and all that stuff.
"why is anyone using C/C++ based mail servers ?"
Because they know more than you.
We are now in the fortunate position where the overheads involved in e.g. Java or C# are counterbalanced by the speed of current machines. But you don't have to rewind too many years for this to not be the case, and then you needed software which isn't bloated to feck and gone with layers of checking to make sure it doesn't do stuff it shouldn't. So all older projects were written in C/C++. (Hell, even coding in C++ was the subject of significant discussion in the 90s, although eventually C++ compilers got smart and came close to C efficiency.)
Suppose someone did write a new mail server in C# though. Sure it might not leave you open to buffer overflows - but the very fact of it being new means that there *WILL* be some bugs in there which might do the wrong thing. At this point any halfway-competent admin would say "bollox to that, I'm not using it until it's had some testing". The risk of language-level issues is far less than the risk of behaviour issues.
That's why C/C++-based developments like Linux, *BSD and Apache are still happily running on. Of course, anyone using them is stupid too, right?
What a security troll . . .
I've bypassed the Debian/Ubuntu Exim for the last 3 years. Been using Exim since Smail post MMDF. I've had so *few* issues with Exim as an MTA (just get me started on sendmail) but frankly the default Exim compiles left out built in "C" library support for SPF and SRS, so I've been compiling by hand for years. Unlike the crazy kernel numbering, the "Upgrade" or "Update" from 4.69 to the 4.71 and 4.72 I'm using is a simple re-compile. All the Exim releases are pretty much bugfixes or integration of other long tested 3rd party add-ons and libraries.
I know it's hard to believe but API style changes in Exim were actually confined to the major release numbers, you know 2.x, 3.x, and now 4.x (years ago I might add).
The attempt by the distro vendors to complicate er uh, simplify the configuration is unbelievable. But even their crazy config schemes regress with the latest exim builds. AFAIK very little core functionality in Exim has been even deprecated over the years, even moving from 3.x to 4.x I cannot recall any show-stoppers, just minor tweaks and more functionality.
Finally I think the fact that vendors never bothered to "update" from 4.69 to 4.70, 4.71, and 4.72 had more to do with the overall stability of the MTA from the start, since it "just worked" they never felt compelled to update it every 1/2 hour. Patching 4.69 is *STUPID*. 4.72 *IS* 4.69 with 3 cumulative patches (READ THE FRAKKIN' RELEASE/PATCH NOTES!). If the distro vendors want forgo minor updates it's their fault. This bug was fixed years ago, 4.70 WAS THE SECURITY PATCH. There are no API regression changes 4.69 to 4.72 that I'm aware of.
... mostly still in existance/use because of inertia.
(Disclosure: I use sendmail in $dayjob and I can write config files WITHOUT using M4)
It's a lot better than it used to be, but there are better alternatives out there.
The hard part is convincing management to allow them - inertia.
At the rate things are going, smtp is likely to be dropped by most entities as "too hard" anyway. 99.999% of what (attempts to) comes in is spam. better to let someone else handle the hassle.
For silent fixing, not a real comment:
The article references version "4.7" erroneously in a couple of places.
The bug was fixed in "4.70", the current recommended release is "4.72".
The full announcement is available at:
Biting the hand that feeds IT © 1998–2019