[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201312152020.rBFKJsbt021584@linus.mitre.org>
Date: Sun, 15 Dec 2013 15:19:54 -0500 (EST)
From: cve-assign@...re.org
To: thoger@...hat.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com,
mpessas@...nsifex.com, vid@...nsifex.com, rvokal@...hat.com,
fweimer@...hat.com
Subject: Re: CVE-2013-2073 transifex-client: Does not validate HTTPS server certificate (fixed in transifex-client v0.9)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> The way certificate check was implemented to fix CVE-2013-2073 was
> incorrect (check was done on "probe" connection, but not the actual
> connection used to transfer data).
>
> This should get a new CVE.
To have two CVEs assigned in response to two different patches for the
same security problem, it's generally necessary for the first patch to
fix some aspect of the problem. If the first patch accomplished
nothing, a total of only one CVE is used.
Here, it seems that the first patch might help with a situation in
which the attacker doesn't have complete man-in-the-middle access, but
the attacker can replace the server. In that case, the attacker
perhaps can't avoid having the probe connection and the later
connection go to the same server. Because of that, checking only the
probe connection might have a security benefit.
(https://github.com/transifex/transifex-client/issues/42 says "MITM
attacker should be able to steal all transferred data by allowing
"probe" connection opened by verify_ssl to connect to the real
transifex server and only intercept subsequent urllib2 connection.")
Use CVE-2013-7110 for the vulnerability in the "actual connection used
to transfer data."
If the above analysis is incorrect, and there are absolutely no cases
in which the original patch had any security benefit, we will reject
one of the two CVEs.
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJSrg4fAAoJEKllVAevmvms4aMH/RhyyOIEV1btaidX23WeV67a
Sv2ROQV0WI66YmdKiGHnNafZfTKt5XluKEQ/DNOJcD/v67sJipiY3eagYWo+01W8
cjNSUvuU5I1qTcSm/86cebip+gRVd+PeMDWItZpR7V/HojQUy1MjrAAXm0q1Td6i
ghbmbVVaUQl8Vuj0nnf5b1+rhZura9huT5KhnTovjgHIvCiKddA6/kKhSahFiTtB
J0vAcI4AQnjqJ/96RXJYTHjdMyWw2vKCib43Cbx5UKahoSIlup+GOFIEsMdHOeId
H3AXB4K5oMi8G2wLzlgEx2yiFzK8tWJkaaSnt0zv9tKehk25JIXwyr25W8wq0F8=
=hLDC
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
