Security Metrics PCI compliance - Exim fails test?

Currently running:
WHM 11.23.2 cPanel 11.23.6-R27698
REDHAT Enterprise 5.2 i686 on standard - WHM X v3.1.0

This one is driving me crazy. I've absolutely looked at everything, updated everything, checked everything, etc. But still, the last three security scans from Security Metrics returns this failure:

The remote host is running a version of the Exim MTA which is vulnerable to several remote buffer overflows. Specifically, if either 'headers_check_syntax' or 'sender_verify = true' is in the exim.conf file, then a remote attacker may be able to execute a classic stack- based overflow and gain inappropriate access to the machine. *** If you are running checks with safe_checks enabled, this may be a false positive as only banners were used to assess the risk! *** It is known that Exim 3.35 and 4.32 are vulnerable. Solution: Upgrade to Exim latest version Risk Factor: High

-- YES - We do indeed have the latest version of Exim installed (see the version readout below).

-- YES - The following are not found in any of our configuration files for Exim: headers_check_syntax, sender_verify and also by-the-way safe_checks (This is logical, because these variables probably only apply to former versions of Exim.)

Here's the latest exim -bV readout:

Exim version 4.69 #1 built 10-Jun-2008 11:34:56
Copyright (c) University of Cambridge 2006
Berkeley DB: Sleepycat Software: Berkeley DB 4.3.29: (September 12, 2006)
Support for: crypteq iconv() PAM Perl OpenSSL Content_Scanning Old_Demime Experimental_SPF Experimental_SRS Experimental_DomainKeys Experimental_DKIM
Lookups: lsearch wildlsearch nwildlsearch iplsearch dbm dbmnz
Authenticators: cram_md5 plaintext spa
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir autoreply pipe smtp
Size of off_t: 8
Configuration file is /etc/exim.conf

Anyone know what could possibly be going on here?

Thanks very much!
Who is Participating?
nociSoftware EngineerCommented:

that means that either it is a generic comment in the Security Metrics scanner,
when exim is detected..., or it is a problem with the scanner matching a version....

IMHO, it is the first. the comment is rather generic, are there newer rule files for this scanner?

I am not aware of any newer version for exim.
nociSoftware EngineerCommented:
Appearantly it cannot determine what version of Exim is running.
You can check if it sais the version in the banner sent to the mail client:

$ telnet mailserver 25  # should respond with:, You disconnect by sending QUIT
220 ServerName ESMTP Exim 4.69 Thu, 09 Oct 2008 01:00:54 +0200
221 ServerName closing connection

... If there is a different banner it might confuse the scanner?
joetacAuthor Commented:
Yes, one would think, but here's what I get locally (replacing the actual server name below):

$ telnet localhost 25
Connected to localhost (
Escape character is '^]'. ESMTP Exim 4.69 #1 Wed, 08 Oct 2008 18:40:55 -0500
220-We do not authorize the use of this system to transport unsolicited,
220 and/or bulk e-mail.

I also get this is what I get when doing this from another server with (something like):'
telnet 25

And of course we've triple checked that the Security Metrics scanner is not being blocked, indeed all other scan tests have passed.
joetacAuthor Commented:
Thanks noci. Do you have any recommendations with regard to what I should recommend to our hosted customer? As in, how they should approach Security Metrics with this issue?
nociSoftware EngineerCommented:
That's a big question...., I don't know your customer or the SM-check tool provider.
Clearly the issues at hand are not in the available exim
Version number in the SM-tool are a bit off, the issues at hand were >30 versions of software back... and quite old (4.33 was issued in may 2004).
So either the testbed fails on a small part or as a whole (which implies that if no updates to SM are available, how accurate is it in the things that DID pass it's test),
Rule of Thumb, blind faith in any tool will get you... And tools that don't update regularly are dangerous.
If they observed a certain reaction to you malicious input like sudden loss of connection they should urge to check logs etc.  HOW the disconnect happenned.
The disconnect might well be intentional, in stead of accidental.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.