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

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