Date: Wed, 2 Dec 2015 09:49:56 +0100 From: Sebastian Krahmer <krahmer@...e.com> To: cve-assign@...re.org, oss-security@...ts.openwall.com, guidovranken@...il.com Subject: Re: Re: CVE Request: dhcpcd 3.x, potentially other versions too Hi On Tue, Dec 01, 2015 at 11:58:11PM -0800, Seth Arnold wrote: > On Tue, Dec 01, 2015 at 11:58:47PM -0500, cve-assign@...re.org wrote: > > MITRE will assign CVE IDs. Do the above references mean that most of > > the changed code lines in dhcp.c.patch correspond to out-of-bounds > > reads shown in the > > http://roy.marples.name/projects/dhcpcd/fdiff?sbs=1&v1=63689c50411b0920&v2=dad877391ea5b128 > > diff, > > I had expected this part of the diff to address the out-of-bounds writes: > > if (out && out != start) > *(out - 1) = ' '; Ack, looks like heap[-1] OOB write to me. > > > the change from "(l = *q++)" to "(l = *q++) && q - p < len" > > corresponds to an out-of-bounds write, > > I must confess that I skimmed the protected code block quickly when coming > to the conclusion that this was out-of-bounds reads -- it's intricate and > involved and the q - p < len check looked correct. But the memcpy(out,...) > call does look like it'd also perform out-of-bounds writes. Recalling from my last analyse, I think this is just an OOB read, because decode_search() is called with out being NULL to count the amount of data to be copied later. Unless this data is somehow modified the next call to decode_search() should have sufficient amount of heap allocated for the memcpy() to be correct. But the loop has an OOB read when counting the data (and later when copying it and there wasnt already a SIGSEGV). > > > the deletion of "free > > (dhcp->dnssearch)" corresponds to a use-after-free, and nothing else > > in the 2012 part of the http://roy.marples.name reference is a new > > vulnerability? (This is just a guess.) > > I should point out that it's my summary that it's a use-after-free -- > Guido said in his report that it is a double-free. I think that both classes are basically the same. After all, maybe quite challenging to exploit for one-packet client side. Sebastian -- ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer@...e.com - SuSE Security Team
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ