

PCRE Heap Overflow in Regex Processing Lets Users Execute Arbitrary Code - muraiki
http://www.securitytracker.com/id/1032453

======
muraiki
I'm not that familiar with PCRE, but I think that this engine is used in a
variety of programming languages -- but not Perl's, as it's used to provide
Perl-compatible regex. PHP's Manual for PCRE links to pcre.org, so it seems
that at least PHP is vulnerable.

[http://php.net/manual/en/intro.pcre.php](http://php.net/manual/en/intro.pcre.php)

Edit: Here's a copy of the actual CVE, which demonstrates the vulnerability
using PHP: [http://www.openwall.com/lists/oss-
security/2015/06/01/6](http://www.openwall.com/lists/oss-
security/2015/06/01/6)

The CVE mentions that PCRE is used in Flash, Apache, and Nginx.

Edit2: Could a mod change the article url to the openwall CVE? It seems that
securitytracker.com is not the most responsive website. Sorry, I should have
linked to the CVE directly.

~~~
trebor
Anyone compiling regex strings in PHP from user input should take care to use
preg_quote(): [http://php.net/manual/en/function.preg-
quote.php](http://php.net/manual/en/function.preg-quote.php) Otherwise, you're
in risky business trusting what a user could send you.

~~~
0x0
Especially since you could otherwise inject "/e" which turns the whole thing
into an eval() !

~~~
Sophistifunk
SERIOUSLY!? eval() from regexes!?

Jebus... Just burn it all down, we're screwed.

~~~
developer1
From the documentation for regex modifiers: "DEPRECATED as of PHP 5.5.0 and
REMOVED as of PHP 7.0.0". Not for much longer.

------
warbiscuit
If I'm reading this right, the exploit is in the regex compilation stage, not
the data matching stage; therefore remote exploitation would require the
server setup to compile attacker-provided regexps, not just setup to run
attacker data through an admin-configured regexp?

If that's the case, a typical nginx/apache config shouldn't be remotely
vulnerable, right? Though I could see some shared hosting scenarios having
some issues.

~~~
TheLoneWolfling
Simple searches could be an issue, however.

------
samch
I build nginx with PCRE, and I'm curious if this vulnerability would impact
nginx in some way. My hope is that since nginx is using it internally and not
accepting randomly-supplied regex strings, then there might be minimal impact.
Can anybody with more knowledge of nginx + PCRE comment on this?

------
chbrown
I guess this means that regular expressions are Turing complete, at least
until a patch arrives?

------
jakozaur
If you take regex as user input, you should use RE2:
[https://github.com/google/re2](https://github.com/google/re2)

Even without this vulnerability, some regexes can be painfully slow.

------
hinkley
Now you have three problems.

------
tobinfricke
A regular expression processing library seems like a great candidate for
something that could be implemented in a "safe" language - Haskell, OCAML,
(Rust?), etc.

------
eridal
wow, I was expecting an odd looking, weird, larger regex, but look at this..

    
    
        /^(?P=B)((?P=B)(?J:(?P<B>c)(?P<B>a(?P=B)))>WGXCREDITS)/
    

is that `WGXCREDITS` the command to execute?

~~~
nly
What does that regex even match?

~~~
ackalker
It is quite possible that the regex doesn't match anything useful. From the
looks of it, I would say it was generated using a fuzzing tool, in much the
same way as what lead to the discovery of the Shellshock vulnerability.

------
timboslice
What does this mean to someone with a public facing website that uses PHP w/
Apache or Nginx?

~~~
mahouse
My guess is that nothing unless you let the user input REs. (Or use REs that
can be modified by user input)

~~~
timboslice
Thank you :)

