Bug 864894 - ssmtp: Does not validate server certificates when using TLS connection
ssmtp: Does not validate server certificates when using TLS connection
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20120307,repor...
: Reopened, Security
: 857483 (view as bug list)
Depends On: 864897 864898
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-10 06:57 EDT by Jan Lieskovsky
Modified: 2015-07-31 02:54 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-04 10:34:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Local copy of proposed Debian patch (4.01 KB, patch)
2012-10-10 06:58 EDT, Jan Lieskovsky
no flags Details | Diff
revised patch (5.20 KB, patch)
2013-07-18 07:59 EDT, Till Maas
no flags Details | Diff

  None (edit)
Description Jan Lieskovsky 2012-10-10 06:57:24 EDT
It was reported that ssmtp, an extremely simple MTA to get mail off the system to a mail hub, did not perform x509 certificate validation when initiating a TLS connection to server. A rogue server could use this flaw to conduct man-in-the-middle attack, possibly leading to user credentials leak.

References:
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662960

CVE Request:
[2] http://www.openwall.com/lists/oss-security/2012/10/10/6

Proposed patch from Debian BTS entry:
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=0003-Validate-the-server-certificate-when-using-TLS.patch;att=1;bug=662960
Comment 1 Jan Lieskovsky 2012-10-10 06:58:42 EDT
Created attachment 624782 [details]
Local copy of proposed Debian patch
Comment 2 Jan Lieskovsky 2012-10-10 06:59:50 EDT
This issue affects the versions of the ssmtp package, as shipped with Fedora release of 16 and 17. Please schedule an update.

--

This issue affects the versions of the ssmtp package, as shipped with Fedora EPEL 5 and Fedora EPEL 6. Please schedule an update.
Comment 3 Jan Lieskovsky 2012-10-10 07:00:52 EDT
Created ssmtp tracking bugs for this issue

Affects: fedora-all [bug 864897]
Affects: epel-all [bug 864898]
Comment 4 manuel wolfshant 2012-10-10 07:01:11 EDT

*** This bug has been marked as a duplicate of bug 857483 ***
Comment 5 Vincent Danen 2012-10-11 11:46:00 EDT
Now that a CVE has been requested, we should have this bug open (please don't resolve bugs in the Security Response product without checking with us first).

However, as indicated in bug #857483, I don't believe this is a security flaw:


A Debian bug was filed about ssmtp not checking certificates:

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

And it includes a patch to enable checking of server certificates when using TLS:

http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=0003-Validate-the-server-certificate-when-using-TLS.patch;att=1;bug=662960

We should include this patch.

Note that this isn't a security _flaw_ because the TLS file in the source tarball clearly states that this feature is missing:


TODO:
* Check server certificate for changes and notify about it.
* Diffrent Certificate and Key file?


This patch would be ideal to have in both Fedora and EPEL ssmtp packages.


(I've posted a followup on oss-sec noting the above).
Comment 6 Vincent Danen 2012-10-11 11:47:11 EDT
*** Bug 857483 has been marked as a duplicate of this bug. ***
Comment 7 manuel wolfshant 2012-10-11 15:32:36 EDT
> 
> However, as indicated in bug #857483, I don't believe this is a security
> flaw:
> 
> 
> A Debian bug was filed about ssmtp not checking certificates:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662960
> 
> And it includes a patch to enable checking of server certificates when using
> TLS:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=0003-Validate-
> the-server-certificate-when-using-TLS.patch;att=1;bug=662960
> 
> We should include this patch.

I will and thank you for extracting the bug and including it here. However I also have a day job which takes precedence in occupying my time.

> Note that this isn't a security _flaw_ because the TLS file in the source
> tarball clearly states that this feature is missing:
I am all in favor of adding features when possible. That's why for instance in Fedora/EPEL ssmtp knows about aliases while the Debian version does not.
Comment 8 Vincent Danen 2012-10-11 17:23:13 EDT
(In reply to comment #7)
... 
> > We should include this patch.
> 
> I will and thank you for extracting the bug and including it here. However I
> also have a day job which takes precedence in occupying my time.

I'm sorry.  I don't know where this comment is coming from... the bug juggling was in no way a reflection of the work you do, or the speed with which you do it.
Comment 9 manuel wolfshant 2012-10-11 18:11:43 EDT
Vincent, I sincerely apologize if you saw my remark as being addressed to you. It was meant just as an explanation of why I move slower than I wished.



In other news: Should the bug remain assigned to RH security team or be transferred to me ? I'd rather have it switched to "ASSIGNED" instead of "NEW" and assigned to me instead of RH security. And BTW, it was bugzilla who closed this bug automatically when marking it as a duplicate of the older bug.
Comment 10 Vincent Danen 2012-10-12 12:12:24 EDT
Yeah, bugzilla does that.  =)

No, this bug shouldn't be reassigned or change state from NEW (standard SRT process).  However, there are bugs filed that you can (and should!) use for fixing in Fedora and EPEL:

(In reply to comment #3)
> Created ssmtp tracking bugs for this issue
> 
> Affects: fedora-all [bug 864897]
> Affects: epel-all [bug 864898]

Those are the bugs you can change to ASSIGNED and go through your standard process with.  Once those have been resolved, SRT will resolve this bug as well.
Comment 11 manuel wolfshant 2012-10-13 00:44:03 EDT
ssmtp-2.64-5.fc18 has been submitted as an update for Fedora 18 and rawhide
https://admin.fedoraproject.org/updates/ssmtp-2.64-5.fc18
Comment 12 Fedora Update System 2012-10-31 21:20:43 EDT
ssmtp-2.61-19.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 13 Fedora Update System 2013-01-16 12:26:06 EST
ssmtp-2.61-19.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 14 Fedora Update System 2013-01-16 12:29:43 EST
ssmtp-2.61-19.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 15 Till Maas 2013-07-18 07:58:19 EDT
The applied patch is broken and actually makes the situation worse, because now the manpage mentions that server certificates are checked, but they are only checked if a client certificate is used.
This was already mentioned in the debian bugtracker:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662960#12

The problem is that the verification happens in the wrong if block. See the revised patch that I will attach.

Also it is not verified that the hostname matches the common name of the certificate as far as I can see. This is not addressed in the revised patch.
Comment 16 Till Maas 2013-07-18 07:59:59 EDT
Created attachment 775292 [details]
revised patch
Comment 17 Fedora Update System 2013-08-30 18:59:02 EDT
ssmtp-2.64-9.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 18 Fedora Update System 2013-08-30 19:00:29 EDT
ssmtp-2.64-9.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 19 manuel wolfshant 2013-09-04 10:41:09 EDT
Please note that updated packages are available via epel-testing for both RHEL 5 & 6.
I'll keep them there for a couple more weeks in the hope that they receive some karma feedback ( good or bad .. )
Comment 20 Till Maas 2013-09-04 11:18:16 EDT
(In reply to manuel wolfshant from comment #19)
> Please note that updated packages are available via epel-testing for both
> RHEL 5 & 6.
> I'll keep them there for a couple more weeks in the hope that they receive
> some karma feedback ( good or bad .. )

From a look to the git master branch it appears that the hostname is not yet verified. Unfortunately this is rather complicate with openssl prior to version 1.1. I intend to ask the openssl maintainer, whether this change can be backported to openssl 1.0 in Fedora, since the support was added by someone in Red Hat security. Otherwise the code might need to be copied into ssmtp.
Comment 21 Vincent Danen 2013-10-04 18:38:05 EDT
(In reply to Till Maas from comment #20)
> (In reply to manuel wolfshant from comment #19)
> > Please note that updated packages are available via epel-testing for both
> > RHEL 5 & 6.
> > I'll keep them there for a couple more weeks in the hope that they receive
> > some karma feedback ( good or bad .. )
> 
> From a look to the git master branch it appears that the hostname is not yet
> verified. Unfortunately this is rather complicate with openssl prior to
> version 1.1. I intend to ask the openssl maintainer, whether this change can
> be backported to openssl 1.0 in Fedora, since the support was added by
> someone in Red Hat security. Otherwise the code might need to be copied into
> ssmtp.

I must admit that I'm confused.  What does the "git master branch" have to do with anything?  The packages were patched, see http://koji.fedoraproject.org/koji/buildinfo?buildID=457626:

* Tue Aug 20 2013 Manuel "lonely wolf" Wolfshant <wolfy@fedoraproject.org> - 2.61-21
- replace TLS patch with a corrected one. thanks Till Maas for the fix

Unless you mean to say that your patch was also wrong?  Can you please explain?
Comment 22 Till Maas 2013-10-07 13:24:51 EDT
(In reply to Vincent Danen from comment #21)
> (In reply to Till Maas from comment #20)

> * Tue Aug 20 2013 Manuel "lonely wolf" Wolfshant <wolfy@fedoraproject.org> -
> 2.61-21
> - replace TLS patch with a corrected one. thanks Till Maas for the fix
> 
> Unless you mean to say that your patch was also wrong?  Can you please
> explain?

My patch is as incomplete as the original patch with respect to hostname verification. Therefore ssmtp accepts any certificate signed by a trusted CA independent of the certificates common name or alternative names.

My patch only ensured that the code from the initial patch to verify certificates against a CA is really used.
Comment 23 Vincent Danen 2013-10-23 17:23:37 EDT
Looking at the Debian bug, I see no movement there at all.  Does a proper patch exist yet, or not?

I guess I'll re-open the tracking bugs to indicate this is not yet fixed properly.
Comment 24 Till Maas 2013-10-24 08:13:48 EDT
(In reply to Vincent Danen from comment #23)
> Looking at the Debian bug, I see no movement there at all.  Does a proper
> patch exist yet, or not?

The proper patch does not yet exist. It will be easy to do so when openssl 1.1 can be used, because only then it will provide a function for this:

https://github.com/openssl/openssl/commit/a70da5b3ecc3160368529677006801c58cb369db


http://docs.fedoraproject.org/en-US/Fedora_Security_Team//html/Defensive_Coding/sect-Defensive_Coding-TLS-Client.html#idm229816036016
Comment 25 Fedora Update System 2014-01-12 14:19:10 EST
ssmtp-2.61-21.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 26 Fedora Update System 2014-01-12 14:20:03 EST
ssmtp-2.61-21.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.