[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <54D1E991.6040001@redhat.com>
Date: Wed, 04 Feb 2015 10:42:41 +0100
From: Florian Weimer <fweimer@...hat.com>
To: oss-security@...ts.openwall.com
CC: cve-assign@...re.org, jsm28@....gnu.org
Subject: Re: Re: CVE request: heap buffer overflow in glibc
swscanf
On 02/04/2015 04:16 AM, cve-assign@...re.org wrote:
>> The check with __libc_use_alloca also checks against the number
>> of array entries to allocate rather than the number of bytes, so
>> the function can allocate up to four times as many bytes as is
>> libc policy on the stack in the wide character case.
>
> Here, it seems that the goal of the policy is risk management for
> use of alloca. This is security relevant for some applications that
> use glibc, because it could (for example) allow a denial of service
> attack that's intended to trigger a failed alloca. There was one
> intended policy, and the the incorrect "__libc_use_alloca
> (newsize)" caused a different (and weaker) policy to be enforced
> instead.
If you want to assign CVE IDs for stack overflows in glibc without
demonstrated application impact, we really need to find a way to
streamline the process because there are quite a few missing assignments.
I wouldn't mind getting a pool of CVEs (for multiple years, going back
to around 2000), and assigning them to issues in the glibc Bugzilla
instance, and posting weekly summaries to oss-security. Would that
work for you?
--
Florian Weimer / Red Hat Product Security
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.
