SoylentNews is people
SoylentNews
A bug in an obscure but widely used email program may be putting as many as 400,000 servers around the world at risk of serious attack until they install an update.
The flaw—which is in all releases of the Exim message transfer agent except for version 4.90.1—opens servers to attacks that can execute malicious code, researchers who discovered the vulnerability warned in an advisory published Tuesday. The buffer overflow vulnerability, which is indexed as CVE-2018-6789, resides in base64 decode function. By sending specially manipulated input to a server running Exim, attackers may be able to remotely execute code.
This discussion has been archived.
No new comments can be posted.
400,000 Servers Using Exim May be at Risk of Serious Code-Execution Attacks
|
Log In/Create an Account
| Top
| 24 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Conquering Russia should be done steppe by steppe.
(Score: 2) by Shimitar on Thursday March 08 2018, @11:34AM (7 children)
And i tought Postfix + Dovecot was all people used.
Coding is an art. No, java is not coding. Yes, i am biased, i know, sorry if this bothers you.
(Score: 0) by Anonymous Coward on Thursday March 08 2018, @11:52AM
Yes, but there's no vuln there, so there's no story to waste the HDD space on, Exim is net superior in this regard. Aren't you grateful for the story to those sub-humans who use it?
Besides, those researchers need to do something to put bread on the table, won't you think if them?
(Score: 2, Interesting) by Anonymous Coward on Thursday March 08 2018, @12:24PM (1 child)
I remember the time some 15 years ago when I was working in a small local isp. One of my duties was to maintain and deal the mailserver. It had sendmail and I started to dislike it a lot, then this slowly turning to hate. For every small change required, configurations had to be modified in 3 places of some weird files which in turn were analysed by that m4 sort of thing. And spam at the time was starting to become more and more a fashion in the world.
It was then when I thought what else there exist in *nix so I can use as a mailserver/mta? So I started looking and found out there were quite a few to chose from. And I couldnt choose, I did not know any of them. Which would give me less headache? Be sensible at configurations? Not suck and turn so easily to an open relay? So I started looking at what came in as a default preinstall at distros. There was RH at the time and it had sendmail. A slackware system we also had was the same. When I went home to check my experimantal new Debian install, it had Exim. So it must be good this Exim thing I thought. Got the documentation and started d to read and advance through it like a schoolbook. Configuration file was easy to read, you could even program in its kind of own language, it made sense... I just loved it in comparison to sendmail.
So a month later I was ready. Had the executable compiled in the server, had created my configfile to match what sendmail had. Waited for the night and at 1am killed sendmail and started exim. Those first hours were intense, I felt like entering and living inside eximlog. But in the end it all turned out good. Though all that first week people would report here and there of things not right or changed behaviour of their mail client, some very weird things which they could not explain. But it all got sorted out and way easier than sendmail. And I felt an evil pride when other people's reaction was "What? You changed away from an already running sendmail? Sendmail is THE mta software, are you crazy?"
Eh, the days.
(Score: 2) by frojack on Thursday March 08 2018, @06:43PM
Yes, now that takes a committee, and letting a contract for a team of consultants.
I did roughly the same migration in our own company after taking copious notes, writing a script, testing dozens of times on my home server.
Then we migrated 14 customer sites as if it were routine maintenance. Which it was, in my view.
When was the last time you heard about a Exim vulnerability? Sendmail had them weekly for a while.
No, you are mistaken. I've always had this sig.
(Score: 4, Insightful) by ledow on Thursday March 08 2018, @01:52PM (2 children)
To be honest, there are certain big-name software that I deliberately just don't touch.
sendmail / Exim are among them.
vi and emacs.
bind.
Pretty much those things are born of an archaic era, and then bolted onto a billion times until they're unusable. I'm by no means scared of a command-line, config-file, or even patching my own bugfix/feature into source code. But there comes a point where you just want to use the machine, rather than spend your life absorbing how to configure something correctly against a wave of decades of ridiculous and obscure options, each change of which kills the service while it's running and puts you at risk of not working, and which failures are logged with obscure and unrelated cruft and not documented anyway.
Postfix doesn't seem to suffer from that. Nor dovecot. On modern distros, apt-get will get you to the point of install of both where you are able to connect and not be in some stupid config by default, and they have configuration files that you can understand, write and transfer from one machine to another easily, logs you can read, and options you can understand.
I feel that clinging to those old programs actually holds us back. bind syntax, for example, is horrendous. I don't think I ever want to configure a zonefile by hand, thanks. I'll use some better tool to do that or, in smaller deployments, just use something else entirely (e.g. dnsmasq). When you then inevitably bolt on things like DNSSEC, IPv6, etc. it quickly becomes stupid.
I was very loathe to use many of these tools because they made life simpler, which often means losing features. But I don't think that's true. I just moved a postfix/opendkim/dovecot config including IPv6, greylisting, spam-filtering, custom header and body checks, virtual domains, other-domain forwards (including multiple-recipient forwards), mailboxes statistics-generating scripts that I wrote, DKIM, POP3, IMAP etc. from one server to another and it was so quick and simple that I was suspicious for a day and a half before realising it had just worked as I intended (even with jumping several version numbers in the process). And this isn't about the age of the software or new paradigms invented - by contrast, I spent an hour looking into systemd's time server before just turning it off and using ntpd instead. It was actually quicker to replace it than to understand how to tweak it to my intentions (and I wasn't doing anything very complicated). And do you know my biggest obstacle? systemd logging. I wanted a mail log file in plain text and it was just easier to install syslog-ng than it was to mess around trying to get the systemd log tools to do what I wanted (I could see the postfix logs, but it was so inconvenient and different to parse, and preserve and ensure future preservation, and log rotation, and so on that I just gave up).
It's about how useful and simple a system wants to be, and how much it considers its users as humans rather than config-wielding robots who shouldn't be allowed near it without ten years of training on that particular software no matter how much of the actual protocol, process etc. they personally understand.
I Let's-Encrypted all my Apache sites. Baffled only by a small issue involving a port assignment in a ServerName directive on a single virtual host, it took about 20 minutes. A problem which was clearly listed in the error log, and basically told me what was wrong. I put up a firewall on a new dedicated server using ufw in about 20 seconds, just enough to secure the machine while I set up the services I needed, without exposing them to the world or blocking my ssh login. Some things just want you to use them. dnsmasq ran my local network for over 10 years, and I think I touched the config about once a year or so, if that, and that was specifically to add in new features not just "keep it running as it always has but securely".
By contrast, does anyone remember the cdrecord tools? Which insisted (still do?) on virtual SCSI names for devices to burn CDs/DVDs even in the drive wasn't actually SCSI at all (e.g. USB/SATA). It's that kind of objectionable "feature", where as a programmer I would go: "Well, it's annoying ME so it must be annoying my users!" and spend an hour or two coding on it so that my internal technical reference ID can be derived from whatever sensible device name the user actually is likely to give me.
There's nothing wrong with plain-text configuration files. I even understand the need for postmap hashed-files etc. on large sites. But some of them I just wouldn't go near, others are borderline and I only play with the bits I understand, and yet some are so open that I BROWSE THROUGH THEM looking for features and switches that I might want to turn on because they look interesting. P.S. If your software ships with a example config file showing commented out descriptions of every possible option and their syntax, and the command line tools show the help when you give no options, and the help alone is enough to derive the majority of command syntax: I love you.
No software is perfect (postqueue to view emails queues, but postsuper to modify/delete from them?), but for me postfix wins hands-down against every other mail server in that regard.
It's about time we realised that "being techy, managing thousands of devices, controlling swathes of important data, machines and services" and "actually likes to be able to pick up a new tool and start working" are not in direct opposition.
Don't even get me started on the docker / PHP hoops I jumped through to get nextcloud up and running on my personal server.
(Score: 2) by darkfeline on Friday March 09 2018, @05:46AM (1 child)
Why is vi and emacs on that list? vi is barely configurable [1], and works out of the box anyway. Emacs is an Emacs Lisp interpreter. Complaining about configuring Emacs is like complaining about configuring Perl. As far as languages go, Perl might actually be below Emacs Lisp since Emacs Lisp is readable (as you can introspect it interactively, no matter how poorly written) while Perl (especially written by a less than perfect programmer) is... less so.
[1]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ex.html#tag_20_40_13_60 [opengroup.org]
Join the SDF Public Access UNIX System today!
(Score: 2) by ledow on Friday March 09 2018, @08:30AM
Usage.
Using a line-editor is a dumb idea in the modern world. There's no use-case where it's sensible compared to a more modern editor.
Emacs is similarly unhelpful, difficult to use, and quicker to replace than it is to try to learn.
Save yourself an AWFUL lot of effort. "apt-get install nano/pico".
(Score: 0) by Anonymous Coward on Thursday March 08 2018, @09:14PM
If they use cPanel, they're using Exim and Dovecot. Unless they're on a really old version of cPanel, anyway, in which case they're using Exim and Courier IMAP. But cPanel backported the patch for this during the embargo.