Bug 681054 (CVE-2011-1071, CVE-2011-1659) - CVE-2011-1071 CVE-2011-1659 glibc: fnmatch() alloca()-based memory corruption flaw
Summary: CVE-2011-1071 CVE-2011-1659 glibc: fnmatch() alloca()-based memory corruption...
Status: CLOSED ERRATA
Alias: CVE-2011-1071, CVE-2011-1659
Product: Security Response
Classification: Other
Component: vulnerability   
(Show other bugs)
Version: unspecified
Hardware: All Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: public=20100805,reported=20110226,sou...
Keywords: Security
: 692259 (view as bug list)
Depends On: 688214 688215 688217 688219 767685 769360
Blocks: 767564
TreeView+ depends on / blocked
 
Reported: 2011-02-28 23:28 UTC by Vincent Danen
Modified: 2018-11-27 21:13 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-02-13 20:55:52 UTC
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
Red Hat Product Errata RHSA-2011:0412 normal SHIPPED_LIVE Important: glibc security update 2011-04-04 20:06:07 UTC
Red Hat Product Errata RHSA-2011:0413 normal SHIPPED_LIVE Important: glibc security update 2011-04-04 20:22:08 UTC
Red Hat Product Errata RHSA-2012:0125 normal SHIPPED_LIVE Moderate: glibc security and bug fix update 2012-02-14 01:33:53 UTC
Sourceware 11883 None None None Never
Sourceware 12583 None None None Never

Description Vincent Danen 2011-02-28 23:28:32 UTC
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 23:30:54 UTC
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 14:16:58 UTC
(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 15:07:26 UTC
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 10:24:59 UTC
(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 05:37:35 UTC
*** Bug 692259 has been marked as a duplicate of this bug. ***

Comment 9 errata-xmlrpc 2011-04-04 20:06:21 UTC
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 20:22:16 UTC
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 16:55:00 UTC
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 20:35:43 UTC
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 20:55:52 UTC
Statement:

(none)


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