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.