637433 – Accepting bad SSL certificate applies to any expected hostname

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 637433 - Accepting bad SSL certificate applies to any expected hostname

Summary: Accepting bad SSL certificate applies to any expected hostname

Keywords:
Status:	CLOSED WONTFIX
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	evolution-data-server
Sub Component:
Version:	6.0
Hardware:	All
OS:	Linux
Priority:	low
Severity:	low
Target Milestone:	rc
Target Release:	---
Assignee:	Matthew Barnes
QA Contact:	Desktop QE
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	818922
TreeView+	depends on / blocked

Reported:	2010-09-25 19:48 UTC by Matt McCutchen
Modified:	2013-06-11 13:06 UTC (History)
CC List:	5 users (show)
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2013-06-11 13:06:07 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
GNOME Bugzilla	606181	0	None	None	None	2019-05-22 06:02:28 UTC
Red Hat Bugzilla	733439	1	None	None	None	2021-01-20 06:05:38 UTC

Internal Links: 733439

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.

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