Link to home
Start Free TrialLog in
Avatar of joetac
joetac

asked on

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!
Avatar of noci
noci

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
QUIT
221 ServerName closing connection

... If there is a different banner it might confuse the scanner?
Avatar of joetac

ASKER

Yes, one would think, but here's what I get locally (replacing the actual server name below):

$ telnet localhost 25
Trying 127.0.0.1...
Connected to localhost (127.0.0.1).
Escape character is '^]'.
220-servername.domain.com 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 100.100.100.100 25


And of course we've triple checked that the Security Metrics scanner is not being blocked, indeed all other scan tests have passed.
ASKER CERTIFIED SOLUTION
Avatar of noci
noci

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of joetac

ASKER

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?
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.