A security vulnerability in Exim

News and announcements regarding Debian. Not for support questions.
Post Reply
Message
Author
User avatar
Telemachus
Posts: 4677
Joined: 2006-12-25 15:53

A security vulnerability in Exim

#1 Post by Telemachus »

Please see these links asap if you are running a mailserver with Exim:
"We have not been faced with the need to satisfy someone else's requirements, and for this freedom we are grateful."
Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System

User avatar
neddie
Posts: 380
Joined: 2009-09-14 07:57

Re: A security vulnerability in Exim

#2 Post by neddie »

I have exim4 installed, but have never heard of it before. How do I know whether it's actually running, or if it can be removed? Is it required for the internal mail server (which as far as I know I never use) or is it only really running if it's set up to receive mail from outside?

User avatar
BenB
Posts: 51
Joined: 2009-12-21 22:36
Location: WV

Re: A security vulnerability in Exim

#3 Post by BenB »

Exim could possibly be used as an SMTP relay on your system. If certain ports are open and exim's configurations aren't done properly this is a valid risk with it on your system. What it could enable is spammers using your system to post mail from and spoof.

I believe however, the default exim light which is pre-installed is set up and configured properly to avoid this. There was just an update via Update Manager which possibly included a security fix for exim. Given this I'd hazard you've little to be concerned about. Granted, I'm not a guru yet so please allow someone more knowledgeable to correct me, and or offer better advice.
In the confrontation between the stream and the rock, the stream always
wins - not through strength, but through persistence. - Anonymous

User avatar
Telemachus
Posts: 4677
Joined: 2006-12-25 15:53

Re: A security vulnerability in Exim

#4 Post by Telemachus »

It's installed by default on many Debian machines (Exim4 is the default MTA, and some MTA is required for cron and such programs). However, it is almost certainly not running as a true external mailserver if you've never touched it. (That is, it's not listening on any open ports.)

That said, a security update just came through, and you should install it. To check if you have, you can follow this advice (from one of the links above):

Bytemark wrote:In order to check and fix a vulnerable server, you will need root shell access and about 10 minutes.

To check what version your server is running, run:

Code: Select all

/usr/sbin/exim -bV
You're safe if any of the following is true:
  • The version is 4.70 or later;
  • The build date is Friday 10th December 2010 or later;
  • It says "No such file or directory" (i.e. you don't run exim).
"We have not been faced with the need to satisfy someone else's requirements, and for this freedom we are grateful."
Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System

User avatar
neddie
Posts: 380
Joined: 2009-09-14 07:57

Re: A security vulnerability in Exim

#5 Post by neddie »

Thanks for the extra info - at least I know I can't remove it without breaking stuff.
Your exim -bv command didn't show me any version number, it just gave me a ">" prompt, but dpkg tells me I've got 4.69-9 (not 4.70 or later as you say), and that matches the numbers in the first link you sent.

User avatar
MeanDean
Posts: 3953
Joined: 2007-09-01 01:14

Re: A security vulnerability in Exim

#6 Post by MeanDean »

The cron package does not depend on an MTA although it does suggest it. So I wouldn't say cron needs an MTA to be functional but would obviously need one to send mail out. Whether or not it needs an MTA to 'send' mail on the local machine is something I am not sure of....anyone ever checked?


I do not use cron so I do not bother with having cron installed or any MTA either.

tnnn
Posts: 5
Joined: 2010-11-20 21:37

Re: A security vulnerability in Exim

#7 Post by tnnn »

neddie wrote:Your exim -bv command didn't show me any version number, it just gave me a ">" prompt,
That is because -bv != -bV (man says that -bv is also a valid switch - just for something else).
It appears that [ code ] block lowercases it - just try copying it and you will get a proper command (/usr/sbin/exim -bV).

User avatar
Telemachus
Posts: 4677
Joined: 2006-12-25 15:53

Re: A security vulnerability in Exim

#8 Post by Telemachus »

tnnn wrote:
neddie wrote:Your exim -bv command didn't show me any version number, it just gave me a ">" prompt,
That is because -bv != -bV (man says that -bv is also a valid switch - just for something else).
Good eye.
tnnn wrote:It appears that [ code ] block lowercases it - just try copying it and you will get a proper command (/usr/sbin/exim -bV).
Really? When I select the text (manually or using the "select all" button, the uppercase V stays uppercase.

@Dean I remembered it being a requirement, not a suggestion, but you may be absolutely right. Cron does need something to send local mail, I believe, but certainly not Exim4.

I usually switch to a smaller, lighter SMTP agent, like msmtp or esmtp or ssmtp.
"We have not been faced with the need to satisfy someone else's requirements, and for this freedom we are grateful."
Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System

User avatar
MeanDean
Posts: 3953
Joined: 2007-09-01 01:14

Re: A security vulnerability in Exim

#9 Post by MeanDean »

....you could just redirect the output to a log file (or even /dev/null) and skip the email stuff

tnnn
Posts: 5
Joined: 2010-11-20 21:37

Re: A security vulnerability in Exim

#10 Post by tnnn »

Telemachus wrote:
tnnn wrote:It appears that [ code ] block lowercases it - just try copying it and you will get a proper command (/usr/sbin/exim -bV).
Really? When I select the text (manually or using the "select all" button, the uppercase V stays uppercase.
Sorry, maybe I was a bit unclear. When you copy it (either by ctrl+c or "select all" option) it works fine as it copies V as it should be - in uppercase. However, if you are too lazy to use the copy function and just type it by hand, you will probably type it incorrectly because [ code ] displays it in lowercase.

And BTW - since exim4 seems to be a part of a default installation, I'd consider pointing it out in the original post (or even thread title).

User avatar
neddie
Posts: 380
Joined: 2009-09-14 07:57

Re: A security vulnerability in Exim

#11 Post by neddie »

tnnn wrote:That is because -bv != -bV
D'oh. good spot. Ok, so -bV also says 4.69, not 4.70 or later, but I'm assuming this is still ok.

oOarthurOo
Posts: 545
Joined: 2008-10-25 12:00
Location: Canada

Re: A security vulnerability in Exim

#12 Post by oOarthurOo »

If you don't use it, lose it.

User avatar
BioTube
Posts: 7551
Joined: 2007-06-01 04:34

Re: A security vulnerability in Exim

#13 Post by BioTube »

tnnn wrote:Sorry, maybe I was a bit unclear. When you copy it (either by ctrl+c or "select all" option) it works fine as it copies V as it should be - in uppercase. However, if you are too lazy to use the copy function and just type it by hand, you will probably type it incorrectly because [ code ] displays it in lowercase.
It's in uppercase; V's just not one of those letters that makes it obvious.
Image
Ludwig von Mises wrote:The elite should be supreme by virtue of persuasion, not by the assistance of firing squads.

tnnn
Posts: 5
Joined: 2010-11-20 21:37

Re: A security vulnerability in Exim

#14 Post by tnnn »

BioTube wrote:It's in uppercase; V's just not one of those letters that makes it obvious.
You are correct, my bad. Those who can't read, have to read man ;)

raboof
Posts: 67
Joined: 2008-08-02 10:47

Re: A security vulnerability in Exim

#15 Post by raboof »

It seems several people are having trouble with the macro expansion of among others MAIN_RELAY_NETS and ETC_MAILNAME in the security-fixed package.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607542

In all cases I've seen so far the machine was rooted as described at http://www.reddit.com/r/netsec/comments ... led_on_my/

rickbol

Re: A security vulnerability in Exim

#16 Post by rickbol »

My machine was rooted by this vulnerabilty. I'm in the process of recovering, and it isn't going well.

I've restored a backup and tried to "upgrade" (which updates to the patched exim4). Unfortunately, exim (and avahi-daemon) failed to start with the exim error being: "user mail was not found" when dpkg tries to run exim4.config. The full apt-get error sequence is:

Setting up exim4-config (4.69-9+lenny1) ...
2010-12-31 15:50:29 Exim configuration error in line 642 of /var/lib/exim4/config.autogenerated.tmp:
user mail was not found
2010-12-31 15:50:29 Exim configuration error in line 642 of /var/lib/exim4/config.autogenerated.tmp:
user mail was not found
2010-12-31 15:50:29 Exim configuration error in line 642 of /var/lib/exim4/config.autogenerated.tmp:
user mail was not found
exim: could not open panic log - aborting: see message(s) above
Invalid new configfile /var/lib/exim4/config.autogenerated.tmp, not installing
/var/lib/exim4/config.autogenerated.tmp to /var/lib/exim4/config.autogenerated
dpkg: error processing exim4-config (--configure):
subprocess post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of exim4-base:
exim4-base depends on exim4-config (>= 4.30) | exim4-config-2; however:
Package exim4-config is not configured yet.
Package exim4-config-2 is not installed.
Package exim4-config which provides exim4-config-2 is not configured yet.
dpkg: error processing exim4-base (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of exim4-daemon-light:
exim4-daemon-light depends on exim4-base (>= 4.69); however:
Package exim4-base is not configured yet.
dpkg: error processing exim4-daemon-light (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of bsd-mailx:
bsd-mailx depends on exim4 | mail-transport-agent; however:
Package exim4 is not installed.
Package mail-transport-agent is not installed.
Package exim4-daemon-light which provides mail-transport-agent is not configured yet.
dpkg: error processing bsd-mailx (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of mailx:
mailx depends on bsd-mailx; however:
Package bsd-mailx is not configured yet.
dpkg: error processing mailx (--configure):
dependency problems - leaving unconfigured
Errors were encountered while processing:
exim4-config
exim4-base
exim4-daemon-light
bsd-mailx
mailx
E: Sub-process /usr/bin/dpkg returned an error code (1)

I've removed\purged exim and tried to reinstall, but get the same error. After hours reading various reports of this exim error, the only "solved" threads (from years ago) were regarding various file permission issues (at least one case regarding /etc/passwd). in my case, strace shows the following file access failures:

38733:610 open("/etc/passwd", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
38735:610 open("/etc/localtime", O_RDONLY) = -1 EACCES (Permission denied)
38742:610 <... open resumed> ) = -1 EACCES (Permission denied)
38750:610 <... open resumed> ) = -1 EACCES (Permission denied)
38764:610 <... open resumed> ) = -1 EACCES (Permission denied)
38767:610 connect(5, {sa_family=AF_FILE, path="/dev/log"...}, 110) = -1 EACCES (Permission denied)
38769:610 open("/dev/console", O_WRONLY|O_NOCTTY) = -1 EACCES (Permission denied)
38771:610 open("/etc/localtime", O_RDONLY) = -1 EACCES (Permission denied)
38774:610 connect(5, {sa_family=AF_FILE, path="/dev/log"...}, 110) = -1 EACCES (Permission denied)
38776:610 open("/dev/console", O_WRONLY|O_NOCTTY) = -1 EACCES (Permission denied)
38778:610 open("/etc/localtime", O_RDONLY) = -1 EACCES (Permission denied)
38781:610 connect(5, {sa_family=AF_FILE, path="/dev/log"...}, 110) = -1 EACCES (Permission denied)
38783:610 open("/dev/console", O_WRONLY|O_NOCTTY) = -1 EACCES (Permission denied)
38785:610 open("/etc/localtime", O_RDONLY) = -1 EACCES (Permission denied)
38788:610 connect(5, {sa_family=AF_FILE, path="/dev/log"...}, 110) = -1 EACCES (Permission denied)
38790:610 open("/dev/console", O_WRONLY|O_NOCTTY) = -1 EACCES (Permission denied)
38792:610 open("/etc/localtime", O_RDONLY) = -1 EACCES (Permission denied)
38795:610 connect(5, {sa_family=AF_FILE, path="/dev/log"...}, 110) = -1 EACCES (Permission denied)
38797:610 open("/dev/console", O_WRONLY|O_NOCTTY) = -1 EACCES (Permission denied)

"chmod 777 /etc/passwd" doesn't help.

Another fix was to modify line 642 of /var/lib/exim4/config.autogenerated.tmp from "user = mail" to "user = 8" (the "number" for the "mail" user?), but the thread rightly suggested that this wasn't advisable.

Anyone have any ideas about what's wrong with /etc/passwd and how to fix it?

Many thanks
rickbol

User avatar
natirips
Posts: 32
Joined: 2010-06-22 10:19
Location: Solar system/~Zagreb

Re: A security vulnerability in Exim

#17 Post by natirips »

rickbol wrote:"chmod 777 /etc/passwd" doesn't help.
Never do that. That would let anyone do whatever they want with your password.

raboof
Posts: 67
Joined: 2008-08-02 10:47

Re: A security vulnerability in Exim

#18 Post by raboof »

rickbol wrote:exim (and avahi-daemon) failed to start with the exim error being: "user mail was not found" when dpkg tries to run exim4.config.
Sorry for perhaps asking the obvious, but do you have a 'mail' user? ;)

User avatar
bugsbunny
Posts: 5355
Joined: 2008-07-06 17:04

Re: A security vulnerability in Exim

#19 Post by bugsbunny »

To check if you have a mail user, and if it's setup correctly:

Code: Select all

# grep mail /etc/passwd /etc/shadow
/etc/passwd:mail:x:8:8:mail:/var/mail:/bin/sh
/etc/shadow:mail:*:14576:0:99999:7:::

mildred

Re: A security vulnerability in Exim

#20 Post by mildred »

I had a similar problem.

My server had its root filesystem on an sdcard, and over time, i got many I/O errors. Today, I replaced it with a hard drive. I copied everything from the exsiting sdcard to the hard disk using `cp -a`. Surprisingly, most things works fine ... except avahi-daemon (and postfix). Also, I could start avahi-daemon, but using --no-drop-root.

Both get permission denied looking at world-readable files, or files they should be able to read anyway.

After looking at everything, I noticed that when I did ls -la /etc, the ".." directory had strange permissions... in fact, when I formatted the hard drive, using disk utilities, It changed ownership of the whole filesystem to my user id. My solution was to do both:

Code: Select all

chown root:root /
chmod 755 /
Everything seems to work fine now !

Post Reply