[Issues] Fwd: regcomp(3) Multiple Vulnerabilities

[Vladimir Levijev <vladimir.levijev@xxxxxxxxx>]

Hi,

Isn't there anyone to comment on the issue? Or is this list dead?

Cheers,

VL

---------- Forwarded message ----------
From: Vladimir Levijev <vladimir.levijev@xxxxxxxxx>
Date: 8 February 2012 20:58
Subject: regcomp(3) Multiple Vulnerabilities
To: issues@xxxxxxxxxx


Hi,

Sorry, if this issue has been discussed or if this is inappropriate
place for such a discussion I'd be glad if you could point me to the
right place.

I'm a developer at Zabbix and we use (and have been using for many
years) libc/regex to provide extended regular expressions support in
our product. Recently we discovered that using a certain valid
(correct me if I'm wrong here) regexp it's possible to crash/hang our
programs on GNU/Linux. The result is either crash or 100% CPU load and
constant memory leak (something like 100 MB in 5 minutes).

An example patterns that do that:

crash: ".*{10,}{10,}{10,}{10,}{10,}"
hang: ".*{10,}{10,}{10,}{10,}"
hang: (.*+++++++++++++++++++++++++++++(\w+))

Example usage:

$ echo foo | grep -E ".*{10,}{10,}{10,}{10,}{10,}"
Segmentation fault

Here is a link to our issue in our issue tracker:

https://support.zabbix.com/browse/ZBX-4625

Debian issue tracker:

http://security-tracker.debian.org/tracker/CVE-2010-4052

Platform used: Debian "Squeeze" (stable), eglibc version: 2.11.3-2

One of the sources describing the issue in more detail:

http://securityreason.com/securityalert/8003

I have tried to get more info how other libc implementations handle
such situations and it appeared NetBSD guys has fixed this issue (see
revision 1.30):

http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/regex/regcomp.c?only_with_tag=MAIN

and the patch doesn't look that big:

http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/regex/regcomp.c.diff?r1=1.29&r2=1.30&only_with_tag=MAIN

I'm sure you are aware of that problem and probably sick of
discussions about it :-) but here go my questions anyway:

1. Are you planning to do anything regarding this issue and if yes,
are there any timelines (or would you accept patches fixing that or
were these already sent by someone)?
2. If the result of the question above is false, do you know of any or
can you recommend any workaround/solution for eglibc users to handle
such situations? We are not considering moving to other library, for
us this is too huge work. Perhaps you could recommend some input
validator that could be used before feeding the regexp to regcomp()?

Thank you,

VL
_______________________________________________
Issues mailing list
Issues@xxxxxxxxxx
http://eglibc.org/cgi-bin/mailman/listinfo/issues