Bug 681054 - (CVE-2011-1071, CVE-2011-1659) CVE-2011-1071 CVE-2011-1659 glibc: fnmatch() alloca()-based memory corruption flaw
CVE-2011-1071 CVE-2011-1659 glibc: fnmatch() alloca()-based memory corruption...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
public=20100805,reported=20110226,sou...
: Security
: 692259 (view as bug list)
Depends On: 688214 688215 688217 688219 767685 769360
Blocks: 767564
  Show dependency treegraph
 
Reported: 2011-02-28 18:28 EST by Vincent Danen
Modified: 2016-02-04 01:47 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-02-13 15:55:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Sourceware 11883 None None None Never
Sourceware 12583 None None None Never

  None (edit)
Description Vincent Danen 2011-02-28 18:28:32 EST
It was reported [1] that glibc had a bug where it would use alloca() for the length of a user-supplied UTF8 string, times four (with additional integer overflow in the times four).  This could lead to an application crash, because alloca() extends the stack.

This was reported upstream [2] and subsequently fixed upstream [3].

References:

[1] http://scarybeastsecurity.blogspot.com/2011/02/i-got-accidental-code-execution-via.html
[2] http://sourceware.org/bugzilla/show_bug.cgi?id=11883
[3] http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=f15ce4d8dc139523fe0c273580b604b2453acba6
Comment 1 Vincent Danen 2011-02-28 18:30:54 EST
This post implies that proftpd is affected (as it pulled its fnmatch implementation from glibc):

http://seclists.org/fulldisclosure/2011/Feb/644
Comment 4 Tomas Hoger 2011-03-08 09:16:58 EST
(In reply to comment #2)
> I tried the demo program on RHEL5 and 6 (32bit each) and it quickly consumed
> all available memory and swap using:
> 
> % ./out 1073741796

If you're just looking to make this crash due to bad alloca use, you can use arg as 25000000, which triggers crash on EL4 - EL6.  I'm not yet sure why integer overflow does not trigger the crash as reported, but that part does not seem to be fixed upstream, as the commit referenced above changes:

  alloca ((n + 1) * sizeof (wchar_t));

to:

  malloc ((n + 1) * sizeof (wchar_t));
Comment 5 Tomas Hoger 2011-03-14 11:07:26 EDT
As mentioned above, there is still an integer overflow in the patched version.  It's not that interesting though, as it only seems to trigger out of bounds reads.  In cases when pattern is untrusted too, this can lead to program crash.  Reported upstream in:
  http://sourceware.org/bugzilla/show_bug.cgi?id=12583
Comment 7 Tomas Hoger 2011-03-18 06:24:59 EDT
(In reply to comment #5)
> As mentioned above, there is still an integer overflow in the patched version. 
> It's not that interesting though, as it only seems to trigger out of bounds
> reads.  In cases when pattern is untrusted too, this can lead to program crash.
> Reported upstream in:
>   http://sourceware.org/bugzilla/show_bug.cgi?id=12583

Fixed upstream via:
  http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=8126d90480fa
Comment 8 Jan Lieskovsky 2011-03-31 01:37:35 EDT
*** Bug 692259 has been marked as a duplicate of this bug. ***
Comment 9 errata-xmlrpc 2011-04-04 16:06:21 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2011:0412 https://rhn.redhat.com/errata/RHSA-2011-0412.html
Comment 10 errata-xmlrpc 2011-04-04 16:22:16 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2011:0413 https://rhn.redhat.com/errata/RHSA-2011-0413.html
Comment 11 Vincent Danen 2011-04-08 12:55:00 EDT
Common Vulnerabilities and Exposures assigned an identifier CVE-2011-1659 to
the following vulnerability:

Name: CVE-2011-1659
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1659
Assigned: 20110408
Reference: http://code.google.com/p/chromium/issues/detail?id=48733
Reference: http://scarybeastsecurity.blogspot.com/2011/02/i-got-accidental-code-execution-via.html
Reference: http://sourceware.org/bugzilla/show_bug.cgi?id=12583
Reference: http://sourceware.org/git/?p=glibc.git;a=commit;h=8126d90480fa3e0c5c5cd0d02cb1c93174b45485
Reference: https://bugzilla.redhat.com/show_bug.cgi?id=681054

Integer overflow in posix/fnmatch.c in the GNU C Library (aka glibc or
libc6) 2.13 and earlier allows context-dependent attackers to cause a
denial of service (application crash) via a long UTF8 string that is
used in an fnmatch call with a crafted pattern argument, a different
vulnerability than CVE-2011-1071.


This CVE has been addressed in the errata noted above and was previously known (see comment #7).
Comment 14 errata-xmlrpc 2012-02-13 15:35:43 EST
This issue has been addressed in following products:

  Red Hat Enterprise Linux 4

Via RHSA-2012:0125 https://rhn.redhat.com/errata/RHSA-2012-0125.html
Comment 15 Vincent Danen 2012-02-13 15:55:52 EST
Statement:

(none)

Note You need to log in before you can comment on or make changes to this bug.