Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ