[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 12 Mar 2015 18:06:27 +0100
From: Alistair Crooks <agc@...src.org>
To: oss-security@...ts.openwall.com
Cc: jmm@...ian.org, cve-assign@...re.org
Subject: Re: Re: CVE request: spencer regexp
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@...re.org
> To: jmm@...ian.org, siddharth@...hat.com
> Cc: cve-assign@...re.org, oss-security@...ts.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-----
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.
