Bug 952194 - (CVE-2013-2073) CVE-2013-2073 transifex-client: Does not validate HTTPS server certificate
CVE-2013-2073 transifex-client: Does not validate HTTPS server certificate
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20130522,repor...
: Security
Depends On: 966171 966172
Blocks: 952191 958854
  Show dependency treegraph
 
Reported: 2013-04-15 07:13 EDT by Florian Weimer
Modified: 2013-12-13 12:35 EST (History)
4 users (show)

See Also:
Fixed In Version: transifex-client 0.9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-17 04:16:03 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Suggested solution for validating SSL certificates in the client (258.43 KB, patch)
2013-05-14 08:40 EDT, Apostolis Bessas
no flags Details | Diff
Fallback to distro-specific paths to SSL certificates bundle (1.67 KB, patch)
2013-05-17 06:05 EDT, Apostolis Bessas
no flags Details | Diff
Deal with http://bugs.python.org/issue17980 (2.88 KB, patch)
2013-05-17 06:05 EDT, Apostolis Bessas
no flags Details | Diff
Deal with Windows (2.79 KB, patch)
2013-05-17 06:12 EDT, Apostolis Bessas
no flags Details | Diff

  None (edit)
Description Florian Weimer 2013-04-15 07:13:04 EDT
I configured /usr/bin/tx to use a server whose certificate is not signed by a trusted CA, and the program still submitted the HTTP request.  Since https:// URLs are strongly recommended by upstream <http://help.transifex.com/features/client/index.html#init>, this constitutes a security issue.

Fixing and disclosing this issue needs to be coordinated with upstream and the Red Hat Security Response Team.
Comment 8 Jan Lieskovsky 2013-05-10 09:53:30 EDT
The CVE identifier of CVE-2013-2073 has been assigned to this issue.
Comment 11 Jan Lieskovsky 2013-05-10 10:48:22 EDT
It was found that Transifex command-line client, a command line tool for Transifex translation management, did not perform X.509 certificate verification when using secured SSL connection. A man-in-the-middle attacker could use this flaw to spoof a Transifex server via an arbitrary certificate.

This issue was discovered by Florian Weimer of the Red Hat Product Security Team.
Comment 12 Jan Lieskovsky 2013-05-10 10:52:16 EDT
This issue affects the versions of the transifex-client package, as shipped with Fedora release of 17 and 18.

--

This issue affects the versions of the transifex-client package, as shipped with Fedora EPEL-5 and Fedora EPEL-6.
Comment 14 Apostolis Bessas 2013-05-14 08:40:22 EDT
Created attachment 747678 [details]
Suggested solution for validating SSL certificates in the client
Comment 15 Apostolis Bessas 2013-05-14 08:46:36 EDT
Comment on attachment 747678 [details]
Suggested solution for validating SSL certificates in the client

We have had some issues with the windows package, so we had to change the patch.

The new version drops the dependency on requests (so that the client is self-contained) and instead uses the same mechanism as requests to verify a SSL certificate. 

The list of root certificates is taken from Mozilla and will be shipped along with the client. The file is licensed under GPLv2, too.

The patch also uses https://bitbucket.org/brandon/backports.ssl_match_hostname/overview, which is licensed under the MIT license, which is also compatible with GPLv2.
Comment 16 Florian Weimer 2013-05-15 03:08:13 EDT
(In reply to comment #14)
> Created attachment 747678 [details]
> Suggested solution for validating SSL certificates in the client

match_hostname has a minor vulnerability.  We should work with Python upstream to disclose/fix this ASAP, so that you don't have to fix your own copy.

For Fedora, we really don't want to ship yet another copy of the root certificate list.  If you could try the paths /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem and /etc/ssl/certs/ca-bundle.crt first before switching to the built-in list, that would help us avoid patching.
Comment 18 Florian Weimer 2013-05-15 07:04:05 EDT
(In reply to comment #17)
> (In reply to comment #16)
> > match_hostname has a minor vulnerability.  We should work with Python
> > upstream to disclose/fix this ASAP, so that you don't have to fix your own
> > copy.
> 
> Reported upstream here: http://bugs.python.org/issue1589 (in a public bug
> because it's so minor)

Correct issue is: http://bugs.python.org/issue17980
Comment 19 Apostolis Bessas 2013-05-17 06:05:02 EDT
Created attachment 749283 [details]
Fallback to distro-specific paths to SSL certificates bundle
Comment 20 Apostolis Bessas 2013-05-17 06:05:57 EDT
Created attachment 749285 [details]
Deal with http://bugs.python.org/issue17980
Comment 21 Apostolis Bessas 2013-05-17 06:12:07 EDT
Created attachment 749288 [details]
Deal with Windows

This is the last (actually, second) patch in the series and just deals with Windows.

The previous two patches dealt with Florian's comments.

Let me know, when you will have contacted the rest of the distros, so that we can release the version 0.9.
Comment 25 Vincent Danen 2013-05-22 13:13:04 EDT
Created transifex-client tracking bugs for this issue

Affects: fedora-all [bug 966171]
Affects: epel-all [bug 966172]
Comment 26 Tomas Hoger 2013-10-30 05:54:26 EDT
(In reply to Apostolis Bessas from comment #15)
> Comment on attachment 747678 [details]
> Suggested solution for validating SSL certificates in the client
> 
> We have had some issues with the windows package, so we had to change the
> patch.
> 
> The new version drops the dependency on requests (so that the client is
> self-contained) and instead uses the same mechanism as requests to verify a
> SSL certificate. 

I had a quick look to see how the check is implemented and it seems there is an issue with the fix.  I may be reading the code incorrect, but it seems transifex-client does:

- verify_ssl opens connection to the target host and verifies provided certificate, including name check
- connection opened by verify_ssl is closed immediately
- actual communication with the server is done via urllib2, which opens its own connection(s)

It seems all data flows though an unverified connection.
Comment 27 Tomas Hoger 2013-10-30 06:15:50 EDT
Opened upstream bug:
https://github.com/transifex/transifex-client/issues/42
Comment 28 Apostolis Bessas 2013-12-04 08:39:02 EST
The client now uses the urllib3 package, which does the SSL verification on opening a request. The changes can be found in the 0.10 version.
Comment 29 Vincent Danen 2013-12-13 12:35:56 EST
See bug #1043002, which is for the "incomplete fix of this CVE" (CVE assignment pending).

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