Bug 681054 (CVE-2011-1071, CVE-2011-1659)

Summary: CVE-2011-1071 CVE-2011-1659 glibc: fnmatch() alloca()-based memory corruption flaw
Product: [Other] Security Response Reporter: Vincent Danen <vdanen>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: alanm, fweimer, jakub, jlieskov, law, rcvalle, rramacha
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
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: --- Target Upstream Version:
Embargoed:
Bug Depends On: 688214, 688215, 688217, 688219, 767685, 769360    
Bug Blocks: 767564    

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)