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.
The CVE identifier of CVE-2013-2073 has been assigned to this issue.
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.
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.
Created attachment 747678 [details] Suggested solution for validating SSL certificates in the client
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.
(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.
(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
Created attachment 749283 [details] Fallback to distro-specific paths to SSL certificates bundle
Created attachment 749285 [details] Deal with http://bugs.python.org/issue17980
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.
Public via: http://blog.transifex.com/post/51072109836/new-version-of-the-transifex-client-has-been-released Relevant upstream patches: https://github.com/transifex/transifex-client/commit/e24ea954373874962f22f63a7311d04d6ff56d84 https://github.com/transifex/transifex-client/commit/f237dd7d3f4f08be7160f32eb99edafe2769aad1 https://github.com/transifex/transifex-client/commit/5246f188b0abcc1a4c20894fcab88f7a6cd6cfd9 https://github.com/transifex/transifex-client/commit/ad29a9dbe869e0c7d861826a82c9ce2f022face4
Created transifex-client tracking bugs for this issue Affects: fedora-all [bug 966171] Affects: epel-all [bug 966172]
(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.
Opened upstream bug: https://github.com/transifex/transifex-client/issues/42
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.
See bug #1043002, which is for the "incomplete fix of this CVE" (CVE assignment pending).