Bug 641373 (CVE-2010-4237)

Summary:	CVE-2010-4237 Mercurial: Doesn't verify subject Common Name
Product:	[Other] Security Response	Reporter:	Jan Lieskovsky <jlieskov>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	mads, mmcgrath, ndbecker2
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-06-11 21:04:18 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:

Description Jan Lieskovsky 2010-10-08 14:51:24 UTC

A security flaw was found in the way Mercurial handled subject
Common Name field of the provided certificate (the check
if the commonName in the received certificate matches the 
requested hostname was not performed). An attacker, able
to get a carefully-crafted certificate signed by a Certificate
Authority could use the certificate during a man-in-the-middle
attack and potentially confuse Mercurial into accepting it by
mistake.

References:
[1] http://mercurial.selenic.com/bts/issue2407
[2] http://bugs.python.org/issue1589
[3] http://svn.python.org/view?view=rev&revision=85321

Upstream changeset:
[4] http://selenic.com/repo/hg-stable/diff/f2937d6492c5/mercurial/url.py

Comment 1 Jan Lieskovsky 2010-10-08 14:54:52 UTC

The true reason for this deficiency is the Python SSL module implementation,
but as stated in:
[5] http://bugs.python.org/issue1589#msg58472

"Unfortunately, hostname matching is one of those ideas that seemed
better when it was thought up than it actually proved to be in practice.
 I've had extensive experience with this, and have found it to almost
always an application-specific decision.  I thought about this when
designing the client-side verification, and couldn't see any automatic
solution that doesn't get in the way.  So the right way to do this with
Python is to write some application code that looks at the verified
identity and makes decisions based on whatever authentication algorithm
you need."

Comment 2 Jan Lieskovsky 2010-10-08 14:55:51 UTC

This issue did NOT affect the versions of the mercurial package, as shipped
with Fedora release of 12 and 13 (relevant packages are already updated).

Comment 4 Neal Becker 2010-10-08 14:58:21 UTC

So should this be closed?

Comment 5 Mads Kiilerich 2010-10-08 15:01:34 UTC

This is fixed with 1.6.4, so it should be closed when that package hits "updates".

Comment 6 Jan Lieskovsky 2010-10-08 15:10:19 UTC

Hi Neal, Mads,

  the Security Response product bugs cover the same issue, present in
particular package among various releases of Red Hat Enterprise Linux 
and Fedora.

  Though this issue has been already addressed in versions of mercurial,
as shipped within Fedora releases, it still applies to version of mercurial,
as scheduled to appear in Red Hat Enterprise Linux 6.

  So this bug being still valid.

Thanks && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team

Comment 7 Jan Lieskovsky 2010-10-08 15:12:28 UTC

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

Comment 8 Huzaifa S. Sidhpurwala 2010-11-16 06:56:13 UTC

Statement:

This issue affects the version of the mercurial package, as shipped with 
Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this issue as having moderate security impact, a future update may address this flaw.

Comment 9 Product Security DevOps Team 2021-06-11 21:04:18 UTC

This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2010-4237