Bug 661909

Summary: bzr: doesn't verify subject Common Name
Product: [Other] Security Response Reporter: Vincent Danen <vdanen>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: a.badger, henrik, shahms, vvitek
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: 2010-12-16 16:00:21 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 Vincent Danen 2010-12-09 23:24:54 UTC
A security flaw was found in the way bzr 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 bzr into accepting it by mistake.

This is similar to CVE-2010-4237 (Mercurial) and shares the same root problem, a deficiency in the Python SSL module implementation.

There does not seem to be an upstream fix or workaround as of yet.

References:

https://bugs.edge.launchpad.net/bzr/+bug/651161
http://bugs.python.org/issue1589
http://svn.python.org/view?view=rev&revision=85321

Comment 1 Vincent Danen 2010-12-10 00:32:22 UTC
Statement:

This issue affects the version of the bzr 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 2 Toshio Ernie Kuratomi 2010-12-10 03:34:17 UTC
Are you sure this affects RHEL6's bzr?  From the launchpad bug this doesn't seem to affect bzr if pycurl is installed.  On both RHEL6 and Fedora we have a requires: on python-pycurl: 

$ rpm -q bzr --qf '%{name}-%{version}-%{release} %{vendor}\n'
bzr-2.1.1-2.el6 Red Hat, Inc.
$ rpm -q --requires bzr |grep curl
python-pycurl

Comment 3 Tomas Hoger 2010-12-10 18:04:47 UTC
(In reply to comment #2)
> Are you sure this affects RHEL6's bzr?  From the launchpad bug this doesn't
> seem to affect bzr if pycurl is installed.

Tested on RHEL6 and F13:

$ host bzr.mozilla.org
bzr.mozilla.org has address 63.245.208.226

$ grep bzr-moz /etc/hosts
63.245.208.226  bzr-moz

$  bzr co https://bzr-moz/bugzilla/trunk bugzilla
bzr: ERROR: pycurl.error: (51, "SSL: certificate subject name '*.mozilla.org' does not match target host name 'bzr-moz'")

Followed by full python trace.

Comment 4 Vincent Danen 2010-12-15 22:18:49 UTC
Yes, I see that requires.  But I also see that if someone were to rpm -e --nodeps python-pycurl, bzr still works:

$ bzr co https://bzr-moz/bugzilla/trunk bugzilla
https://bzr-moz/bugzilla/trunk/ is permanently redirected to https+urllib://www.mozilla.org/bugzilla/trunk/
bzr: ERROR: Not a branch: "https+urllib://www.mozilla.org/bugzilla/trunk/".

This may not be supported, because the requirement is there, but people do strange things.  I think it still needs to be fixed.  Maybe we can force bzr to bail if pycurl isn't available, indicating the module needs to be installed?

I'm more than happy to call this impact=low because of the rpm requires, but until/unless bzr itself bails if pycurl isn't installed, can we really say it's not a security issue at all?

Ahh, hang on.

For correctness I'd like to see this fixed in Fedora at least (it should be fixed upstream also).  However, since yum requires pycurl (which I have just noticed when trying to reinstall it), removing pycurl will break yum.  In light of that, we can call this non-security (if you remove pycurl on RHEL6/Fedora you will have bigger problems than this), but I do still think it's a bug that should be fixed (in Fedora or upstream).

Comment 5 Tomas Hoger 2010-12-16 08:43:18 UTC
Right, with bzr requiring python-pycurl, which is also required by yum, you're unlikely to have affected install (which would be "broken" anyway).  Getting upstream fix to Fedora via newer upstream version sounds like a reasonable approach here.

Comment 6 Vincent Danen 2010-12-16 16:00:21 UTC
Agreed.

I don't know when a new upstream release with this fix will come out, but Fedora is pretty good about keeping up to date, so we can make the assumption that it will just land anyways.

I'm going to close this as NOTABUG because in the context of Fedora and RHEL, you would have much bigger problems with pycurl not being installed than this (this would be the least of your concerns, I think).