A security flaw was found in the regular expression matching routine of glibc, the GNU libc libraries, processed multibyte characters input. If an application utilized the glibc's regular expression matching mechanism, an attacker could provide a specially-crafted input that, when processed would lead to that executable crash. Upstream bug report: [1] http://sourceware.org/bugzilla/show_bug.cgi?id=15078 Relevant patch: [2] http://sourceware.org/ml/libc-alpha/2013-01/msg00967.html
This issue affects the versions of the glibc package, as shipped with Red Hat Enterprise Linux 5 and 6. -- This issue affects the versions of the glibc package, as shipped with Fedora release of 16, 17, and 18. Please schedule an update.
Created glibc tracking bugs for this issue Affects: fedora-all [bug 905877]
CVE request: [3] http://www.openwall.com/lists/oss-security/2013/01/30/1
Jan, Is there some reason trackers weren't created for this issue on RHEL as well? Seems strange that we know this affects both Fedora & RHEL yet we're only tracking fixes for Fedora. From your end, how serious does this appear -- I'm trying to figure out if we will need a 5.9-z or if it can just wait for 5.10. Similarly are we going to need a 6.3-z, 6.4-z or can it wait for 6.5.
Jeff, it looks like this is rated low-impact (crash-only, the buffer is overrun but not with anything the attacker can control), so we're likely to defer this until a more opportune time to fix (pushing a low-impact glibc update isn't something we like to do, as most people would reboot for a glibc update). I suspect a statement to that effect will be written once a CVE is assigned. That would also be why there are no RHEL trackers as of yet.
I'm reviewing Andreas' upstream patch. This is also the same as BZ#905413, but I don't see that bug linked anywhere. https://bugzilla.redhat.com/show_bug.cgi?id=905413
This was assigned CVE-2013-0242.
First pass review done. http://www.sourceware.org/ml/libc-alpha/2013-01/msg01002.html
Secunia advisory: https://secunia.com/advisories/51951/
The only impact of this flaw is a crash. This does not seem to be exploitable, since the buffer overrun is not attacker controlled. Statement: This issue affects the version of glibc as shipped with Red Hat Enterprise Linux 5 and 6. The Red Hat Security Response Team has rated this issue as having low security impact, a future update may address this flaw.
Doing a second pass review, and hope to get a fix for this completed by the end of the day.
Given the low priority of this issue I've allowed a couple of other issue get ahead of this one in the queue. I'm back to this issue now and reviewing again. Upstream has been fixed as of Tuesday January 29th.
Fixed in rawhide. Working on F18.
Working on F19 also.
Fixed in F19. Koji build here: http://koji.fedoraproject.org/koji/taskinfo?taskID=5135287 The F18 patch needed some more pre-requisites to be backported. Thus local testing for F18 is not yet complete.
(In reply to comment #15) Thank you, Carlos. > Fixed in F19. > > Koji build here: > http://koji.fedoraproject.org/koji/taskinfo?taskID=5135287 > > The F18 patch needed some more pre-requisites to be backported. Thus local > testing for F18 is not yet complete. What about Fedora 17 yet? (it's still supported too) Thank you, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team
Fixed in F18. Koji build here: http://koji.fedoraproject.org/koji/taskinfo?taskID=5138634
(In reply to comment #16) > (In reply to comment #15) > > Thank you, Carlos. > > > Fixed in F19. > > > > Koji build here: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=5135287 > > > > The F18 patch needed some more pre-requisites to be backported. Thus local > > testing for F18 is not yet complete. > > What about Fedora 17 yet? (it's still supported too) > > Thank you, Jan. > -- > Jan iankko Lieskovsky / Red Hat Security Response Team On it's way. Added bug 922889 to track F17.
Current status is as follows: - F20 fixed. - F19 fixed. - F18 in bodhi waiting. - F17 in koji building. That should cover everything.
Status update: - F17 in bodhi waiting. That completes fixes to all the supported Fedora branches (modulo bodhi).
(In reply to comment #22) > Status update: > - F17 in bodhi waiting. > > That completes fixes to all the supported Fedora branches (modulo bodhi). Thank you, Carlos.
I tested the Fedora 18 build (glibc-2.16-30.fc18.x86_64), and don't think you fixed things correctly. This unit test (stripped from gnulib's m4/regex.m4 file) fails: $ cat foo.c #define _GNU_SOURCE 1 #include <limits.h> #include <locale.h> #include <regex.h> #include <signal.h> #include <stddef.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/stat.h> #include <unistd.h> int main (void) { int result = 0; static struct re_pattern_buffer regex; const char *s; if (setlocale (LC_ALL, "en_US.UTF-8")) { /* This test is from glibc bug 15078. The test case is from Andreas Schwab in <http://www.sourceware.org/ml/libc-alpha/2013-01/msg00967.html>. */ static char const pat[] = "[^x]x"; static char const data[] = "\xe1\x80\x80\xe1\x80\xbb\xe1\x80\xbd\xe1\x80\x94\xe1\x80" "\xba\xe1\x80\xaf\xe1\x80\x95\xe1\x80\xbax"; re_set_syntax (0); memset (®ex, 0, sizeof regex); s = re_compile_pattern (pat, sizeof pat - 1, ®ex); if (s) result |= 1; else { int i = re_search (®ex, data, sizeof data - 1, 0, sizeof data - 1, 0); if (i != 21) { printf ("Oops, i = %d\n", i); result |= 2; } } } return result; } $ ./foo; echo $? Oops, i = 0 2 At least the failure is no longer a segv, but gnulib is still rejecting the glibc implementation as broken.
(In reply to comment #24) > At least the failure is no longer a segv, but gnulib is still rejecting the > glibc implementation as broken. That is an orthogonal issue to fixing the CVE. This patch fixes the immediate buffer overrun but does nothing to fix the underlying problems required to fix the test case you posted for my_MM.UTF-8 script processing. Does that clarify the situation?
(In reply to comment #25) > (In reply to comment #24) > > At least the failure is no longer a segv, but gnulib is still rejecting the > > glibc implementation as broken. > > That is an orthogonal issue to fixing the CVE. > > This patch fixes the immediate buffer overrun but does nothing to fix the > underlying problems required to fix the test case you posted for my_MM.UTF-8 > script processing. My test was in en_US.UTF-8, not my_MM.UTF-8, but that doesn't affect the outcome. > > Does that clarify the situation? Okay, so the regex implementation is still buggy until a newer glibc is released, but it no longer has a security vulnerability so this particular BZ can be deemed as fixed. I guess the goal of minimal churn for plugging the CVE, instead of completely fixing the bug in the regex engine at the cost of more complicated backports, is acceptable from a risk-management standpoint.
(In reply to comment #26) > (In reply to comment #25) > > Does that clarify the situation? > > Okay, so the regex implementation is still buggy until a newer glibc is > released, but it no longer has a security vulnerability so this particular > BZ can be deemed as fixed. I guess the goal of minimal churn for plugging > the CVE, instead of completely fixing the bug in the regex engine at the > cost of more complicated backports, is acceptable from a risk-management > standpoint. Exactly. I'm glad we agree.
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2013:0769 https://rhn.redhat.com/errata/RHSA-2013-0769.html
glibc-2.15-59.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2013:1605 https://rhn.redhat.com/errata/RHSA-2013-1605.html
Statement: (none)