Home page logo

oss-sec logo oss-sec mailing list archives

Re: Re: CVE-2013-2073 transifex-client: Does not validate HTTPS server certificate (fixed in transifex-client v0.9)
From: Tomas Hoger <thoger () redhat com>
Date: Mon, 16 Dec 2013 10:10:33 +0100

On Sun, 15 Dec 2013 15:19:54 -0500 (EST) cve-assign () mitre org wrote:

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).

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.

That's not consistent with guidance I've seen in the past - if update
is released claiming to fix some issue without actually fixing it, new
CVE is needed.  Not doing so leads to inconsistent security update data
with two different updates or package versions of the same component
being listed as fixing the same CVE.  Release text can probably explain
id reuse, and consider it sufficient for human consumption, but it's
probably more upsetting to tools processing machine readable versions
of update notifications (e.g. OVAL).

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.

Yes, I can agree with that.  Previous patch makes it more difficult for
MITM attacker to perform their attack, as they can no longer intercept
all connections, but they need to let certain connections pass through
and intercept other.

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.

As mentioned above, I believe the fact that 0.9 was previously
announced to fix CVE-2013-2073 should be sufficient to trigger new CVE
assignment regardless of how incomplete the original fix is.

Thank you!

Tomas Hoger / Red Hat Security Response Team

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]