Re: Re: CVE request: spencer regexp

[Alistair Crooks <agc () pkgsrc org>]

We looked at that in our initial assessment:

from http://www.regular-expressions.info/php.html:

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

        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.

Alistair

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: cve-assign () mitre org
> To: jmm () debian org, siddharth () redhat com
> Cc: cve-assign () mitre org, oss-security () lists openwall com
> Sent: Wednesday, March 11, 2015 10:41:59 PM
> Subject: [oss-security] Re: CVE request: spencer regexp
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > http://www.kb.cert.org/vuls/id/695940
> > https://guidovranken.wordpress.com/2015/02/04/full-disclosure-heap-overflow-in-h-spencers-regex-library-on-32-bit-systems/
>
> http://openwall.com/lists/oss-security/2015/02/07/14 says "I have to
> admit we're having a hard time trying to think of a service that
> exposes regcomp(3) over the internet."
>
> http://openwall.com/lists/oss-security/2015/02/16/8 says "in many
> cases the code is only used when building for Android or Windows" and
> indirectly refers to multiple bugs such as:
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778396
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778395
>
> 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 http://cve.mitre.org/cve/request_id.html ]
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (SunOS)
>
> iQEcBAEBAgAGBQJVAHbeAAoJEKllVAevmvmsucwIAJBGMGBHsZg1oKSFhEn2wCJ7
> el1LhsIHmAk0R4rQ1E5IAQFgfNvZ5dA0lagHA7V3prYCM5rgtgGzPTA6SE0Bljl7
> rTCcxZKxs9jXJKnQsV566sdqUcN86WX8ZKp/IqBLxMa9uufi+fbdDeSYGU5R4rF4
> JvrLoRWokvdwkOxB+M4mykKKeEV0+52hBmmC/xxUdVJPdwgTEvL+SL93q8XQlZNN
> BKaFoF6sczCxwWo50u/87qUY44hkwTonHIw6ABWELPH6f0+pgG6T5vlbYS1HVPfn
> XcY6Sz4iyYmtt5AElhwRHaMVuG9EYuHtILPz+Fd5H84ePf18LYe+VQAzZl4S3Jk=
> =7w/F
> -----END PGP SIGNATURE-----