Bug 952194 (CVE-2013-2073) - CVE-2013-2073 transifex-client: Does not validate HTTPS server certificate
Summary: CVE-2013-2073 transifex-client: Does not validate HTTPS server certificate
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2013-2073
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=moderate,public=20130522,repor...
Depends On: 966171 966172
Blocks: 952191 958854
TreeView+ depends on / blocked
 
Reported: 2013-04-15 11:13 UTC by Florian Weimer
Modified: 2019-06-08 19:31 UTC (History)
4 users (show)

Fixed In Version: transifex-client 0.9
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-17 08:16:03 UTC


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

Description Florian Weimer 2013-04-15 11:13:04 UTC
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 13:53:30 UTC
The CVE identifier of CVE-2013-2073 has been assigned to this issue.

Comment 11 Jan Lieskovsky 2013-05-10 14:48:22 UTC
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 14:52:16 UTC
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 12:40:22 UTC
Created attachment 747678 [details]
Suggested solution for validating SSL certificates in the client

Comment 15 Apostolis Bessas 2013-05-14 12:46:36 UTC
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 07:08:13 UTC
(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 11:04:05 UTC
(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 10:05:02 UTC
Created attachment 749283 [details]
Fallback to distro-specific paths to SSL certificates bundle

Comment 20 Apostolis Bessas 2013-05-17 10:05:57 UTC
Created attachment 749285 [details]
Deal with http://bugs.python.org/issue17980

Comment 21 Apostolis Bessas 2013-05-17 10:12:07 UTC
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 17:13:04 UTC
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 09:54:26 UTC
(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 10:15:50 UTC
Opened upstream bug:
https://github.com/transifex/transifex-client/issues/42

Comment 28 Apostolis Bessas 2013-12-04 13:39:02 UTC
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 17:35:56 UTC
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.