Bug 263340 - VUL-0: php: PMOPB-45-2007:PHP ext/filter Email Validation Vulnerability
VUL-0: php: PMOPB-45-2007:PHP ext/filter Email Validation Vulnerability
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE 10.2
Classification: openSUSE
Component: Security
Final
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Security Team bot
E-mail List
CVE-2007-1900: CVSS v2 Base Score: 5....
:
Depends on:
Blocks: 270938
  Show dependency treegraph
 
Reported: 2007-04-11 15:01 UTC by Marcus Meissner
Modified: 2009-10-13 23:11 UTC (History)
3 users (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2007-04-11 15:01:30 UTC
post month of php bugs ...

http://www.php-security.org/MOPB/PMOPB-45-2007.html

The first Post Month of PHP Bugs vulnerability describes a vulnerability in PHP's new input filtering/validation extension. The FILTER_VALIDATE_EMAIL filter of ext/filter internally uses a wrong regular expression that allows injecting a newline character at the end of the email string.

Affected versions

Affected is PHP 5.2.0 and PHP 5.2.1
Comment 1 Cristian Rodríguez 2007-04-11 19:08:22 UTC
not yet fixed,

./sapi/cli/php test.php 
string(17) "test@example.com
"

shoudld be "bool false".

/sapi/cli/php -v
PHP 5.2.2RC2-dev (cli) (built: **Apr 11 2007** 15:07:07) (DEBUG)




Comment 2 Cristian Rodríguez 2007-04-11 19:34:55 UTC
proposed fix

--- ext/filter/logical_filters.c        1 Jan 2007 09:36:00 -0000       1.1.2.21
+++ ext/filter/logical_filters.c        11 Apr 2007 19:13:18 -0000
@@ -469,7 +469,7 @@
 void php_filter_validate_email(PHP_INPUT_FILTER_PARAM_DECL) /* {{{ */
 {
        /* From http://cvs.php.net/co.php/pear/HTML_QuickForm/QuickForm/Rule/Email.php?r=1.4 */
-       const char regexp[] = "/^((\\\"[^\\\"\\f\\n\\r\\t\\b]+\\\")|([\\w\\!\\#\\$\\%\\&\\'\\*\\+\\-\\~\\/\\^\\`\\|\\{\\}]+(\\.[\\w\\!\\#\\$\\%\\&\\'\\*\\+\\-\\~\\/\\^\\`\\|\\{\\}]+)*))@((\\[(((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9])))\\])|(((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9])))|((([A-Za-z0-9\\-])+\\.)+[A-Za-z\\-]+))$/";
+       const char regexp[] = "/^((\\\"[^\\\"\\f\\n\\r\\t\\b]+\\\")|([\\w\\!\\#\\$\\%\\&\\'\\*\\+\\-\\~\\/\\^\\`\\|\\{\\}]+(\\.[\\w\\!\\#\\$\\%\\&\\'\\*\\+\\-\\~\\/\\^\\`\\|\\{\\}]+)*))@((\\[(((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9])))\\])|(((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9])))|((([A-Za-z0-9\\-])+\\.)+[A-Za-z\\-]+))$/D";

        pcre       *re = NULL;
        pcre_extra *pcre_extra = NULL;


(just missing the D modifier)
Comment 3 Lubomir Rintel 2007-04-12 07:57:01 UTC
Apart from that CVE says that this is a CRLF injection, and \n is not CRLF in GNU/Linux, what is the real risk here? I can't think of any situation when you can inject SMTP commands that can be achieved with just one line break. Though I haven't extensively tested it I am pretty confident, that SMTP server would just complain about malformed RCPT TO: command and refuse to send a message. Which is pretty sane, as there's nothing better than not sending a message when you do not have a valid e-mail address.
Comment 4 Ludwig Nussel 2007-04-12 08:04:48 UTC
Yeah, calling that a vulnerability sounds like an overstatement.
Comment 7 Cristian Rodríguez 2007-04-12 08:09:24 UTC
(In reply to comment #3)
> Apart from that CVE says that this is a CRLF injection, and \n is not CRLF in
> GNU/Linux, what is the real risk here? 

I think this issue is pretty minor, yes.

>I can't think of any situation when you
> can inject SMTP commands that can be achieved with just one line break.

Indeed. It may be hard or impossible, even more when this extension is not really  widely used in applications ( google code search returns 4 matches (1 being PHP itself)

Comment 8 Ludwig Nussel 2007-04-12 08:44:23 UTC
CVE-2007-1900 (under review)
   Status Candidate
   Description CRLF injection vulnerability in the FILTER_VALIDATE_EMAIL filter in ext/filter in PHP 5.2.0 and 5.2.1 allows context-dependent attackers to inject arbitrary e-mail headers via an e-mail address with a '\n' character, which causes a regular expression to ignore the subsequent
   part of the address string.
   [14]References
     * MISC:http://www.php-security.org/MOPB/PMOPB-45-2007.html
     * BID:23359
     * URL:http://www.securityfocus.com/bid/23359
     * SECUNIA:24824
     * URL:http://secunia.com/advisories/24824

   Phase Assigned (20070410)
Comment 9 Lubomir Rintel 2007-04-12 11:12:41 UTC
$ cat php.ini
extension=filter.so
sendmail_path=/bin/cat
$ cat PMOPB-45-2007.php
<?php
        require_once 'Mail.php';

        $address = "usser@example.com\n\n\n";
        $subject = 'PMOPB-45-2007';
        $body = "Hugs and kisses to Stefan!";

        $mailers = array (
                'mail' => Mail::factory('mail'),
                'sendmail' => Mail::factory('sendmail', array(
                        'sendmail_path' => '/bin/cat',
                        'sendmail_args' => '; true')),
                'smtp' => Mail::factory('smtp', array(
                        'debug' => TRUE))
        );

        foreach ($mailers as $backend => $mailer) {
                echo ("===== $backend backend =====\n");
                $mailer->send($address, array(
                        'Subject' => $subject,
                        'To' => $address,
                        'From' => 'anotheruser@example.com'),
                        $body);
                echo ("\n");
        }

?>
$ php PMOPB-45-2007.php
===== mail backend =====
To: usser@example.com
Subject: PMOPB-45-2007
From: anotheruser@example.com

Hugs and kisses to Stefan!

===== sendmail backend =====
Subject: PMOPB-45-2007
To: usser@example.com



From: anotheruser@example.com

Hugs and kisses to Stefan!
===== smtp backend =====
DEBUG: Recv: 220 pluto.brq.redhat.com ESMTP Postfix
DEBUG: Send: EHLO localhost

DEBUG: Recv: 250-pluto.brq.redhat.com
DEBUG: Recv: 250-PIPELINING
DEBUG: Recv: 250-SIZE 10240000
DEBUG: Recv: 250-VRFY
DEBUG: Recv: 250-ETRN
DEBUG: Recv: 250-ENHANCEDSTATUSCODES
DEBUG: Recv: 250-8BITMIME
DEBUG: Recv: 250 DSN
DEBUG: Send: MAIL FROM:<anotheruser@example.com>

DEBUG: Recv: 250 2.1.0 Ok
DEBUG: Send: RCPT TO:<usser@example.com>

DEBUG: Recv: 250 2.1.5 Ok
DEBUG: Send: DATA

DEBUG: Recv: 354 End data with <CR><LF>.<CR><LF>
DEBUG: Send: Subject: PMOPB-45-2007
To: usser@example.com



From: anotheruser@example.com

Hugs and kisses to Stefan!
.

DEBUG: Recv: 250 2.0.0 Ok: queued as BCF821F700CC
DEBUG: Send: QUIT

DEBUG: Recv: 221 2.0.0 Bye

$


In real life (apart from that filter extension is never used in real life) no mail backend available for PHP does do any harm. mail() backend saintizes the address. sendmail and smtp backends do not do so, but both smtp extension and sendmail generate proper SMTP headers, so the worst things that happen is that parts of what was meant to be a MIME headers gets into message body. Doh. Critically critical in a critical way.
Comment 10 Lubomir Rintel 2007-04-12 15:03:58 UTC
Oh, and when it comes to SMTP, the extra blank line does no harm, except for "500 5.5.2 Error: bad syntax" error code returned by the server (at least postfix). Moreover, sendmail command from both Postfix and Sendmail remove leading and trailing whitespace from email address given as command line arguments. Obviously, sesser spared his best issue for the end of the MOPB.
Comment 11 Ales Nosek 2007-04-26 12:26:28 UTC
Created patches for 10.2 and Stable: php-*-CVE-2007-1900.patch
Comment 12 Cristian Rodríguez 2007-04-26 12:29:10 UTC
and official fix has not been commited to the PHP CVS. I'll check why ...
Comment 13 Ales Nosek 2007-05-02 16:29:49 UTC
Submitted fixed packages. This bug was fixed in:

php5-10.2
Comment 14 Ludwig Nussel 2007-05-03 14:41:29 UTC
tracked in #270938
Comment 15 Cristian Rodríguez 2007-05-04 06:23:25 UTC
identical fix applied to PHP CVS, not part of PHP 5.2.2 though ( I wonder why it is not there..)
Comment 16 Cristian Rodríguez 2007-05-04 10:23:00 UTC
fixed in buildservice too ( to be merged to Factory when possible)
Comment 17 Thomas Biege 2009-10-13 23:11:52 UTC
CVE-2007-1900: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:P/A:N)