[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 16 Dec 2013 10:10:33 +0100
From: Tomas Hoger <thoger@...hat.com>
To: oss-security@...ts.openwall.com
Cc: cve-assign@...re.org, mpessas@...nsifex.com, vid@...nsifex.com,
rvokal@...hat.com, fweimer@...hat.com
Subject: Re: Re: CVE-2013-2073 transifex-client: Does not
validate HTTPS server certificate (fixed in transifex-client v0.9)
On Sun, 15 Dec 2013 15:19:54 -0500 (EST) cve-assign@...re.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
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.
