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
This post implies that proftpd is affected (as it pulled its fnmatch implementation from glibc): http://seclists.org/fulldisclosure/2011/Feb/644
(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));
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
(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
*** Bug 692259 has been marked as a duplicate of this bug. ***
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
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
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).
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
Statement: (none)