|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:||NEW ---||QA Contact:|
|Version:||unspecified||CC:||mads, mmcgrath, ndbecker2|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
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:  http://mercurial.selenic.com/bts/issue2407  http://bugs.python.org/issue1589  http://svn.python.org/view?view=rev&revision=85321 Upstream changeset:  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:  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:  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.