Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 12 Mar 2015 18:06:27 +0100
From: Alistair Crooks <>
Subject: Re: Re: CVE request: spencer regexp

We looked at that in our initial assessment:


	PHP is an open source language for producing dynamic web pages.  PHP
	has three sets of functions that allow you to work with regular

	The most important set of regex functions start with preg.  These
	functions are a PHP wrapper around the PCRE library (Perl-Compatible
	Regular Expressions).  Anything said about the PCRE regex flavor in
	the regular expressions tutorial on this website applies to PHP's preg
	functions.  When the tutorial talks about PHP specifically, it assumes
	you're using the preg functions.  You should use the preg functions
	for all new PHP code that uses regular expressions.  PHP includes PCRE
	by default as of PHP 4.2.0 (April 2002).

	The oldest set of regex functions are those that start with ereg. 
	They implement POSIX Extended Regular Expressions, like the
	traditional UNIX egrep command.  These functions are mainly for
	backward compatibility with PHP 3.  They are officially deprecated as
	of PHP 5.3.0.  Many of the more modern regex features such as lazy
	quantifiers, lookaround and Unicode are not supported by the ereg
	functions.  Don't let the "extended" moniker fool you.  The POSIX
	standard was defined in 1986, and regular expressions have come a long
	way since then.

So unsanitised remote regular expressions and using the deprecated
ereg in old php?  Possible, but unlikely.  I'm not standing in the way
of CVE assignment, but this is getting towards the theoretical end of
the spectrum.


On Thu, Mar 12, 2015 at 10:18:47AM -0400, Siddharth Sharma wrote:
> Hi,
> That seems to be possible via php, using php_ereg(), php_ereg_replace() , php_ereg_split() 
> which might call regcomp() in backend.
> Regards,
> -------------------------------------------
> Siddharth Sharma / Red Hat Product Security 
> ----- Original Message -----
> From:
> To:,
> Cc:,
> Sent: Wednesday, March 11, 2015 10:41:59 PM
> Subject: [oss-security] Re: CVE request: spencer regexp
> Hash: SHA1
> >
> >
> says "I have to
> admit we're having a hard time trying to think of a service that
> exposes regcomp(3) over the internet."
> says "in many
> cases the code is only used when building for Android or Windows" and
> indirectly refers to multiple bugs such as:
> For example:
>   Package: cups
>   The regex copy is only used when building on Windows. I double-checked
>   by removing the entire vcnet/regex directory and rebuilding cups.
> This is potentially ambiguous. We thought that "when building on
> Windows" would imply something like "if a user is following the steps
> in the CUPS INSTALL.txt file on a Windows machine, then that user is
> able to provide malicious input to the regcomp function during one of
> those steps." It now appears that what was meant was "The problematic
> regcomp function is present in a Windows build of CUPS. Any
> exploitation could occur only after the build has finished."
> In general, when one oss-security post suggests that an issue may not
> be realistically exploitable with untrusted input (e.g., "having a
> hard time trying to think of a service" above), and no other
> oss-security post suggests that the issue is realistically
> exploitable, then there might not be a CVE assignment.
> Here, we'll propose an exploitation scenario for comment. We think
> that this is (at least marginally) realistic, although it might not
> be. Unless there's an objection stating that no realistic exploitation
> scenario can exist, we'll assign a CVE ID for the original regcomp bug
> this week.
> Example:
>   Someone develops a new email filtering language as an alternative
>   to Sieve (RFC 5228). Like Sieve, the language's scripts are
>   intended to run on a mail server that does not permit arbitrary
>   code execution by ordinary mailbox owners. In the new language,
>   the match type of ":matches" is implemented with regcomp.
>   There is no limit on script size, and thus the 682 Mb requirement
>   from the regcomp bug report isn't a concern. It is plausible that
>   an ordinary mailbox owner can create a script that triggers the
>   bug and achieves remote code execution on the mail server.
> - -- 
> CVE assignment team, MITRE CVE Numbering Authority
> M/S M300
> 202 Burlington Road, Bedford, MA 01730 USA
> [ PGP key available through ]
> Version: GnuPG v1.4.14 (SunOS)
> el1LhsIHmAk0R4rQ1E5IAQFgfNvZ5dA0lagHA7V3prYCM5rgtgGzPTA6SE0Bljl7
> rTCcxZKxs9jXJKnQsV566sdqUcN86WX8ZKp/IqBLxMa9uufi+fbdDeSYGU5R4rF4
> JvrLoRWokvdwkOxB+M4mykKKeEV0+52hBmmC/xxUdVJPdwgTEvL+SL93q8XQlZNN
> BKaFoF6sczCxwWo50u/87qUY44hkwTonHIw6ABWELPH6f0+pgG6T5vlbYS1HVPfn
> XcY6Sz4iyYmtt5AElhwRHaMVuG9EYuHtILPz+Fd5H84ePf18LYe+VQAzZl4S3Jk=
> =7w/F

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.