php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #52929 Segfault in filter_var with FILTER_VALIDATE_EMAIL with large amount of data
Submitted: 2010-09-27 02:09 UTC Modified: 2010-11-16 21:31 UTC
From: neufeind@php.net Assigned: aharvey (profile)
Status: Closed Package: Filter related
PHP Version: 5.3.3 OS:
Private report: No CVE-ID: 2010-3710
View Developer Edit
 [2010-09-27 02:09 UTC] neufeind@php.net 
Description:
------------
Using the attached test-script with just a large amount of data (e.g. 8kb of just "x") segfaults php. Tried with 5.3.3 (Fedora) and also some 5.3.4-snapshot that I could get hold of.

Crashed for me with around 8kb of data. If it works fine for you, maybe increase that limit to 16kb or so.

Test script:
---------------
<?php
  $email = file_get_contents('x.data');
  $r = filter_var($email, FILTER_VALIDATE_EMAIL);
  var_dump($r);

// and just dump a large number of characters like "x" in x.data
// for a in `seq 1 8000`; do echo -n x>>x.data; done

Expected result:
----------------
bool(false)

Actual result:
--------------
segfault

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-09-27 02:38 UTC] neufeind@php.net 
Looking at the source at
http://svn.php.net/viewvc/php/php-src/trunk/ext/filter/logical_filters.c?view=markup
I wonder if the problem itself might be in the pcre-lib used since the email-validation itself is PCRE-based? Fedora Linux here ships with PCRE 7.8.
 [2010-09-27 04:16 UTC] felipe@php.net
-Package: Unknown/Other Function +Package: Filter related
 [2010-09-27 05:19 UTC] aharvey@php.net 
This is the normal issue with heavily nested regular expressions
exhausting the available stack size. I can upload a backtrace if
there's a sudden desire to see several thousand recursive
invocations of PCRE's match function. :)

I'm not really comfortable closing this, even though we normally just close 
preg_replace
 [2010-09-27 05:21 UTC] aharvey@php.net 
I hate you, Chrome.

Anyway, as I was saying, I'm not terribly comfortable closing this, 
since it's likely sites will actually be passing user data straight to 
filter_var(). I mean, that's what it's there for. Is it worth
revisiting the decision to compile our bundled libpcre in its default
stack recursive mode? I know NO_RECURSE is slower, but I'm nervous
about potential remote crashers.
 [2010-09-27 07:24 UTC] rasmus@php.net 
Perhaps a simple pre-filter before we hit the regex.  You can't actually have an 
8k email address.  There are length limits both before and after the @.
 [2010-09-27 08:47 UTC] aharvey@php.net
-Status: Open +Status: Assigned -Assigned To: +Assigned To: aharvey
 [2010-09-27 08:47 UTC] aharvey@php.net 
Fair call; I'll prosecute the argument for NO_RECURSE elsewhere!

The limit on address length is 320 octets per RFC 2821 (64 octet 
local-part + 1 octet "@" + 255 octet domain), so we may as well set
the limit there for now. (If RFC 5336 becomes widespread, that may
need to be revisited, but let's cross that bridge when we come to it.)
Any system that's so stack constrained for that to be an issue is
likely to have other problems anyway. :)

Fix for 5.3 and trunk forthcoming, just as soon as I write a test.
 [2010-09-27 09:00 UTC] neufeind@php.net 
Well, then how about please at least adding a pre-filter as rasmus suggested? For the special case (I agree) of email-validation that should be possible.
 [2010-09-27 09:08 UTC] aharvey@php.net 
Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=303779
Log: Fix bug #52929 (Segfault in filter_var with FILTER_VALIDATE_EMAIL with large
amount of data).
 [2010-09-27 09:08 UTC] aharvey@php.net
-Status: Assigned +Status: Closed
 [2010-09-27 09:08 UTC] aharvey@php.net 
This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.
 [2010-09-28 15:03 UTC] support at hosting-agency dot de 
This problem is also included in PHP version 5.2.14
 [2010-09-28 15:12 UTC] felipe@php.net 
Hi, 5.2.x branch is in security bug fixes only. :)
 [2010-09-28 15:14 UTC] neufeind@php.net 
Well, a remotely triggerable segfault might be worth a security-thought/backport of such a minimal invasive patch, wouldn't it? :-)
 [2010-09-28 16:43 UTC] f dot stolle at hosting-agency dot de 
The problem exists also in PHP 5.2.14.
 [2010-09-29 05:31 UTC] aharvey@php.net 
@Stefan: It might be. I've pinged Ilia and Johannes to look at it and
decide if they want it merged to 5.2.
 [2010-09-30 04:35 UTC] aharvey@php.net 
Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=303885
Log: MFH: Fix for bug #52929 (Segfault in filter_var with FILTER_VALIDATE_EMAIL with
large amount of data).
 [2010-09-30 04:36 UTC] aharvey@php.net 
Merged to 5.2.
 [2010-10-19 11:57 UTC] pajoye@php.net 
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=304507
Log: - update #52929 and zip NULL deref
 [2010-10-19 12:15 UTC] pajoye@php.net 
CVE-2010-3710 has been created for this issue.
 [2010-10-19 12:16 UTC] pajoye@php.net 
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=304508
Log: - update #52929 and zip NULL deref
 [2010-11-16 21:31 UTC] felipe@php.net
-CVE-ID: +CVE-ID: 2010-3710
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 11:01:29 2024 UTC