oss-sec mailing list archives
Re: CVE request: heap buffer overflow in glibc swscanf
From: cve-assign () mitre org
Date: Tue, 3 Feb 2015 22:16:41 -0500 (EST)
-----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-----
Current thread:
- CVE request: heap buffer overflow in glibc swscanf Paul Pluzhnikov (Feb 01)
- Re: CVE request: heap buffer overflow in glibc swscanf cve-assign (Feb 03)
- Re: Re: CVE request: heap buffer overflow in glibc swscanf Daniel Micay (Feb 03)
- Re: Re: CVE request: heap buffer overflow in glibc swscanf Florian Weimer (Feb 04)
- <Possible follow-ups>
- Re: CVE request: heap buffer overflow in glibc swscanf Gsunde Orangen (Feb 03)
- Re: CVE request: heap buffer overflow in glibc swscanf cve-assign (Feb 03)