Bug 637433

Summary:	Accepting bad SSL certificate applies to any expected hostname
Product:	Red Hat Enterprise Linux 6	Reporter:	Matt McCutchen <matt>
Component:	evolution-data-server	Assignee:	Matthew Barnes <mbarnes>
Status:	CLOSED WONTFIX	QA Contact:	Desktop QE <desktop-qa-list>
Severity:	low	Docs Contact:
Priority:	low
Version:	6.0	CC:	mbarnes, mcrha, rcvalle, tpelka, vdanen
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-06-11 13:06:07 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	818922

Description Matt McCutchen 2010-09-25 19:48:21 UTC

I reported this security issue upstream and more recently offered a patch, but upstream has not yet acted. I presume the issue affects evolution-data-server in Fedora, so the Fedora maintainers might wish to take my patch or work with upstream to speed the resolution of the issue.

Description of problem:
If I accept a bad SSL certificate for a mail server, the certificate and
expected hostname are saved to ~/.evolution/camel-cert.db. But then Evolution
will accept the certificate for any expected hostname, not just the saved one.
Thus, the first mail server can impersonate the mail servers for my other
accounts. This is a big vulnerability if you care about SSL.

Version-Release number of selected component (if applicable):
Upstream 2.28 development branch. I have not tested the Fedora version, but I presume it is affected.

How reproducible:
Always

Steps to Reproduce:
1. If you are not using a throwaway user account, back up ~/.evolution/camel-cert.db and ~/.camel_certs to restore after testing.
2. Get the test server kit from the upstream bug (https://bugzilla.gnome.org/attachment.cgi?id=170062).
3. Run the test server in a terminal with "./run-server 1".
4. Start the wizard to create a new mail account, and complete the "Identity" page with dummy values.
5. On the "Receiving Email" page, set the server to "127.0.0.1:4433", choose "SSL encryption", and click "Check for Supported Types" to trigger an SSL/TLS connection.
6. When the bad certificate dialog appears, click OK.
7. Type a Ctrl-D to the server to close the connection. (Evolution will indicate failure to check the supported authentication types, which doesn't matter here.)
8. Change the server to "localhost:4433" and click "Check for Supported Types" again.
9. When you are finished testing, cancel out of the wizard and if applicable, exit Evolution and restore ~/.evolution/camel-cert.db and ~/.camel_certs .

Actual results:
The certificate is silently accepted in step 8.

Expected results:
The bad certificate dialog should appear again.

Additional info:
My patch is at https://bugzilla.gnome.org/attachment.cgi?id=170061 . Note that it makes breaking changes to the camel certdb API in libcamel-1.2.so to support the new bad-certificate code. This API is public, but I don't think it's really intended for use outside evolution-data-server, and in fact nothing in Fedora 13 except for evolution-data-server uses it. (I ran "repoquery --whatrequires 'libcamel-1.2.so.14()(64bit)'", downloaded all the listed packages except evolution-data-server, and grepped for references to camel_certdb.)

Comment 1 Matt McCutchen 2010-09-25 19:58:59 UTC

This bug is like CVE-2008-2809 in Mozilla applications, except the certificate is accepted for any hostname whatsoever, not just the ones listed in the certificate.  A mitigating factor is that a user typically uses a few hand-picked mail servers, which are less likely to be malicious than a random web site for which he/she might be persuaded to accept a bad certificate.

Comment 2 Vincent Danen 2010-09-27 21:08:43 UTC

Thank you for the report.  As a reference, the original upstream report is here:

https://bugzilla.gnome.org/show_bug.cgi?id=606181

Comment 3 Vincent Danen 2010-09-27 21:51:56 UTC

This is indeed interesting.

I can reproduce this, _until_ I restart the wizard.  For instance, on the first try, I first try:

- localhost:4433/SSL/IMAP --> warns of bad cert --> click OK, kill and restart test server
- 127.0.0.1:4433/SSL/IMAP --> no complaint
- exit evolution wizard (click cancel)
- restart evolution wizard
- 127.0.0.1:4433/SSL/IMAP --> warns of bad cert --> click cancel
- localhost:4433/SSL/IMAP --> warns of bad cert

So it looks as though this allowing all bad certs is session-dependant; it doesn't persist across sessions (perhaps with invocations of the wizard only, not sure?).

Do you get the same behaviour?  It seems as though accepting one bad cert won't allow you to accept bad certs forever, just in that instance.

Comment 4 Vincent Danen 2010-09-27 21:58:41 UTC

It also looks like this behaviour of warning about bad certificates is relatively new; evolution on RHEL5 does not warn about the bad cert (looks like it takes bad certs all the time), so the strange inconsistency is with newer evolution (the above was tested with F13; I've not tried earlier to see when this behaviour might have been introduced).

Comment 9 Matt McCutchen 2011-01-11 23:38:18 UTC

Finally getting back to this issue...

(In reply to comment #3)
> I can reproduce this, _until_ I restart the wizard.  For instance, on the first
> try, I first try:
> 
> - localhost:4433/SSL/IMAP --> warns of bad cert --> click OK, kill and restart
> test server
> - 127.0.0.1:4433/SSL/IMAP --> no complaint
> - exit evolution wizard (click cancel)
> - restart evolution wizard
> - 127.0.0.1:4433/SSL/IMAP --> warns of bad cert --> click cancel
> - localhost:4433/SSL/IMAP --> warns of bad cert
> 
> So it looks as though this allowing all bad certs is session-dependant; it
> doesn't persist across sessions (perhaps with invocations of the wizard only,
> not sure?).

I see the behavior you describe when I run Evolution for the first time in a user account, so that the wizard opens immediately and Evolution quits if the wizard is canceled.  The non-persistence is apparently the result of the mail session not being shut down properly in this case (arguably a bug).  But if I complete the wizard once so that the main Evolution UI comes up, from that point on, all cert exceptions persist even across application restarts.

Comment 14 Milan Crha 2011-11-29 10:08:17 UTC

I cannot reproduce this with 2.28.3 of evolution and evolution-data-server, same as the current stable 3.2.2 and current git master 3.3.2, as I stated in:
https://bugzilla.gnome.org/show_bug.cgi?id=606181#c7

The main question, are you sure you run the second server, not the first? Because that's the only difference which can explain what you see. I can provide a simple test patch which will show what fingerprints are received and tested and such, to be sure we all see the same, if you wish.

Comment 15 Milan Crha 2011-12-01 09:46:27 UTC

Matt explained me in the upstream bug what I did wrong in my steps. I continue discussion there first.

Comment 17 Suzanne Logcher 2012-02-14 23:03:19 UTC

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Comment 18 Milan Crha 2013-05-09 12:38:22 UTC

(In reply to comment #15)
> Matt explained me in the upstream bug what I did wrong in my steps. I
> continue discussion there first.

The upstream change made it for 3.5.1+/3.5.2+.

Comment 21 RHEL Program Management 2013-06-11 13:06:07 UTC

Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.