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
Created attachment 624782 [details] Local copy of proposed Debian patch
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.
Created ssmtp tracking bugs for this issue Affects: fedora-all [bug 864897] Affects: epel-all [bug 864898]
*** This bug has been marked as a duplicate of bug 857483 ***
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).
*** Bug 857483 has been marked as a duplicate of this bug. ***
> > 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.
(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.
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.
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.
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
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.
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.
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.
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.
Created attachment 775292 [details] revised patch
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.
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.
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 .. )
(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.
(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> - 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?
(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> - > 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.
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.
(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
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.
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.
This CVE Bugzilla entry is for community support informational purposes only as it does not affect a package in a commercially supported Red Hat product. Refer to the dependent bugs for status of those individual community products.
* Ok. with your patches, the server-certificate is checked if it is valid and is authorized by a trustful certification-authority. * One problem still remains: * It is relatively simple to get an authorized certificate for whatever domain-name. * So someone could divert the connection to a server that is not actually the correct mailhub. --> the (fully qualified) domain-name of that fake mailhub would not match (simply) said the (fully qualified) domain-name in the certificate, but the certificate would be verified successfully. * I am going to make a patch (basics work!) that checks the mailhub name against either the "commonName" (CN) or 'DNS:...'-entries in the "Subject Alternate Name"-field in the certificate. * A pre-pre...prep-release of the patch and code can be seen at * patch for "smtp.c": "http://www.thomas-r-bruecker.ch/favorites/io/com/mail/ssmtp.git/patch" * code that actually checks: "http://www.thomas-r-bruecker.ch/favorites/io/com/mail/ssmtp.git/check_mailhub.ci" INTERESTED ?
Thomas, thank you very much for your interest and offer for help. Unfortunately in the last 6 years I gradually replaced all the instances of ssmtp I installed 10 years ago so my interest for it has decreased dramatically and I am no longer able to offer it the love it needs.
(Continuing comment #28:) Besides that the program does not check every error-condition and lacks of some error-messages, it should work, and check correctly now (say -beta-beta) == and it is full of developing-printout to the console.