[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 3 Feb 2015 22:16:41 -0500 (EST)
From: cve-assign@...re.org
To: ppluzhnikov@...il.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com, jsm28@....gnu.org
Subject: Re: CVE request: heap buffer overflow in glibc swscanf
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> https://sourceware.org/bugzilla/show_bug.cgi?id=16618
> stdio-common/vfscanf.c has an ADDW macro that tries to determine
> whether to use malloc or alloca for allocations. But in the malloc
> case, it only allocates newsize bytes instead of the required
> newsize * sizeof (CHAR_T). Thus the allocated buffer gets overrun in
> the wide-string case
( referring to
https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=blob_plain;f=stdio-common/vfscanf.c;hb=HEAD )
Use CVE-2015-1472 for this issue in which an incorrect second argument
to realloc leads to a buffer overflow.
> The logic also has a problem that the comparison UCHAR_MAX + 1 >
> 2 * wpmax doesn't allow for 2 * wpmax overflowing, though that would
> only apply if half the address space gets allocated.
We think you mean that the integer overflow isn't reachable because,
on platforms supported by glibc, the ADDW macro wouldn't be used in a
case where "2 * wpmax" overflows. The value of wpmax is limited by the
requirement that that value was previously used in a successful
realloc call. If the realloc had failed, a "goto errout" would have
occurred.
If this is incorrect and the integer overflow actually is reachable
when operating on very long input data, then a separate CVE ID can be
assigned for the integer overflow. In any case, the integer overflow
is not within the scope of CVE-2015-1472.
> 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.
Use CVE-2015-1473 for this risk-management error.
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJU0Y4mAAoJEKllVAevmvmsgBUIAMj4u37bJEH/oibsqjXHcSgz
C1XY1mZej/ojdVuAmWyiX1MZGUDzhaLEz6AdRjhQg7BtdVUfdQ1PjV8q+PT8gORD
nuIwWYT281XbIuVkJ2YT2Su789FxylQeOYhzl2rDyKecc+J24v/eL7PNFNrcYy2+
1/i+q2FXFS0lP6QcvZbWlEryJzWl4sN47LIwvhreRsWFH5N4o7x6It7mzE3yRu5O
YAb52wRPABFWDozyYgDc06qood/Gyok1eCBzkhuO7MRO4dAjWexPh2oEg7mFkygM
6FM/P6wNbN/n5Hqx39+PE/TQCKVuWZFcrATFugFiWSVWPBlEQjJpcctJv2TNQC8=
=lBV+
-----END PGP SIGNATURE-----
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.
