Bug 641373 (CVE-2010-4237) - CVE-2010-4237 Mercurial: Doesn't verify subject Common Name
Summary: CVE-2010-4237 Mercurial: Doesn't verify subject Common Name
Alias: CVE-2010-4237
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2010-10-08 14:51 UTC by Jan Lieskovsky
Modified: 2021-06-11 21:04 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2021-06-11 21:04:18 UTC

Attachments (Terms of Use)

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

[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

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):


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