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.