Bug 905874 - (CVE-2013-0242) CVE-2013-0242 glibc: Buffer overrun (DoS) in regexp matcher by processing multibyte characters
CVE-2013-0242 glibc: Buffer overrun (DoS) in regexp matcher by processing mul...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20130129,reported=2...
: Security
Depends On: 905413 905877 922866 922889 951130 951132 951213
Blocks: 905879 947890 974906
  Show dependency treegraph
 
Reported: 2013-01-30 06:15 EST by Jan Lieskovsky
Modified: 2016-02-04 01:47 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
A flaw was found in the regular expression matching routines that process multibyte character input. If an application utilized the glibc regular expression matching mechanism, an attacker could provide specially-crafted input that, when processed, would cause the application to crash.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-22 00:25:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Gentoo 454862 None None None Never

  None (edit)
Description Jan Lieskovsky 2013-01-30 06:15:10 EST
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
Comment 1 Jan Lieskovsky 2013-01-30 06:17:07 EST
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.
Comment 2 Jan Lieskovsky 2013-01-30 06:18:17 EST
Created glibc tracking bugs for this issue

Affects: fedora-all [bug 905877]
Comment 3 Jan Lieskovsky 2013-01-30 06:43:16 EST
CVE request:
[3] http://www.openwall.com/lists/oss-security/2013/01/30/1
Comment 4 Jeff Law 2013-01-30 09:17:18 EST
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.
Comment 5 Vincent Danen 2013-01-30 12:25:00 EST
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.
Comment 6 Carlos O'Donell 2013-01-30 13:37:42 EST
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
Comment 7 Vincent Danen 2013-01-30 20:43:08 EST
This was assigned CVE-2013-0242.
Comment 8 Carlos O'Donell 2013-01-30 23:48:29 EST
First pass review done.

http://www.sourceware.org/ml/libc-alpha/2013-01/msg01002.html
Comment 9 Jan Lieskovsky 2013-01-31 12:45:24 EST
Secunia advisory:
  https://secunia.com/advisories/51951/
Comment 10 Huzaifa S. Sidhpurwala 2013-02-05 04:32:11 EST
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.
Comment 11 Carlos O'Donell 2013-02-05 08:39:39 EST
Doing a second pass review, and hope to get a fix for this completed by the end of the day.
Comment 12 Carlos O'Donell 2013-02-25 11:30:18 EST
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.
Comment 13 Carlos O'Donell 2013-03-17 20:18:56 EDT
Fixed in rawhide.

Working on F18.
Comment 14 Carlos O'Donell 2013-03-17 20:37:57 EDT
Working on F19 also.
Comment 15 Carlos O'Donell 2013-03-17 23:58:48 EDT
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.
Comment 16 Jan Lieskovsky 2013-03-18 13:29:24 EDT
(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
Comment 17 Carlos O'Donell 2013-03-18 13:47:08 EDT
Fixed in F18.

Koji build here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5138634
Comment 18 Carlos O'Donell 2013-03-18 13:58:03 EDT
(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.
Comment 21 Carlos O'Donell 2013-03-19 15:14:33 EDT
Current status is as follows:
- F20 fixed.
- F19 fixed.
- F18 in bodhi waiting.
- F17 in koji building.

That should cover everything.
Comment 22 Carlos O'Donell 2013-03-19 18:56:59 EDT
Status update:
- F17 in bodhi waiting.

That completes fixes to all the supported Fedora branches (modulo bodhi).
Comment 23 Jan Lieskovsky 2013-03-20 04:08:03 EDT
(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.
Comment 24 Eric Blake 2013-03-21 17:11:36 EDT
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 (&regex, 0, sizeof regex);
        s = re_compile_pattern (pat, sizeof pat - 1, &regex);
        if (s)
            result |= 1;
        else
        {
            int i = re_search (&regex, 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.
Comment 25 Carlos O'Donell 2013-03-21 18:11:50 EDT
(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?
Comment 26 Eric Blake 2013-03-21 18:48:18 EDT
(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.
Comment 27 Carlos O'Donell 2013-03-22 08:59:24 EDT
(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.
Comment 30 errata-xmlrpc 2013-04-24 13:37:39 EDT
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
Comment 32 Fedora Update System 2013-06-01 21:58:21 EDT
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.
Comment 33 errata-xmlrpc 2013-11-21 05:42:44 EST
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
Comment 34 Huzaifa S. Sidhpurwala 2013-11-22 00:25:38 EST
Statement:

(none)

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