Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <504DD06A.9060209@redhat.com>
Date: Mon, 10 Sep 2012 13:35:06 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Jeff Law <law@...hat.com>
CC: Kurt Seifried <kseifried@...hat.com>, oss-security@...ts.openwall.com,
        Jan Lieskovsky <jlieskov@...hat.com>,
        "Steven M. Christey" <coley@...us.mitre.org>,
        Jakub Jelinek <jakub@...hat.com>
Subject: Re: CVE Request -- glibc: strcoll() integer overflow
 leading to buffer overflow + another alloca() stack overflow issue (upstream
 #14547 && #14552)

On 09/07/2012 07:29 PM, Jeff Law wrote:

>>> If I have looked correctly this is expected / known behaviour of
>>> alloca() - from the manual page: [4]
>>> http://linux.die.net/man/3/alloca

> Just because it's known/expected behaviour doesn't mean it's not a
> potential attack vector.  Blowing out the stack is definitely a vector
> for attack:

I agree.  If the frame address leaks or can be deduced, an unbounded 
alloca (or VLA) can be abused as a POKE.  I think this might apply in 
this case because the writes to the allocated memory area are incremental.

-- 
Florian Weimer / Red Hat Product Security 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.