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: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | unspecified | CC: | 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
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) |