Bug #52929 [Com]: Segfault in filter_var with FILTER_VALIDATE_EMAIL with large amount of data

2010-09-28 Thread support at hosting-agency dot de
Edit report at http://bugs.php.net/bug.php?id=52929edit=1

 ID: 52929
 Comment by: support at hosting-agency dot de
 Reported by:neufe...@php.net
 Summary:Segfault in filter_var with FILTER_VALIDATE_EMAIL
 with large amount of data
 Status: Closed
 Type:   Bug
 Package:Filter related
 PHP Version:5.3.3
 Assigned To:aharvey
 Block user comment: N

 New Comment:

This problem is also included in PHP version 5.2.14


Previous Comments:

[2010-09-27 09:08:13] ahar...@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-27 09:08:06] ahar...@php.net

Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=303779
Log: Fix bug #52929 (Segfault in filter_var with FILTER_VALIDATE_EMAIL
with large
amount of data).


[2010-09-27 09:00:05] neufe...@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 08:47:09] ahar...@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 07:24:16] ras...@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 @.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

http://bugs.php.net/bug.php?id=52929


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=52929edit=1


Bug #52929 [Com]: Segfault in filter_var with FILTER_VALIDATE_EMAIL with large amount of data

2010-09-28 Thread neufe...@php.net
Edit report at http://bugs.php.net/bug.php?id=52929edit=1

 ID: 52929
 Comment by: neufe...@php.net
 Reported by:neufe...@php.net
 Summary:Segfault in filter_var with FILTER_VALIDATE_EMAIL
 with large amount of data
 Status: Closed
 Type:   Bug
 Package:Filter related
 PHP Version:5.3.3
 Assigned To:aharvey
 Block user comment: N

 New Comment:

Well, a remotely triggerable segfault might be worth a
security-thought/backport of such a minimal invasive patch, wouldn't it?
:-)


Previous Comments:

[2010-09-28 15:12:37] fel...@php.net

Hi, 5.2.x branch is in security bug fixes only. :)


[2010-09-28 15:03:26] support at hosting-agency dot de

This problem is also included in PHP version 5.2.14


[2010-09-27 09:08:13] ahar...@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-27 09:08:06] ahar...@php.net

Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=303779
Log: Fix bug #52929 (Segfault in filter_var with FILTER_VALIDATE_EMAIL
with large
amount of data).


[2010-09-27 09:00:05] neufe...@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.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

http://bugs.php.net/bug.php?id=52929


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=52929edit=1


Bug #52929 [Com]: Segfault in filter_var with FILTER_VALIDATE_EMAIL with large amount of data

2010-09-28 Thread f dot stolle at hosting-agency dot de
Edit report at http://bugs.php.net/bug.php?id=52929edit=1

 ID: 52929
 Comment by: f dot stolle at hosting-agency dot de
 Reported by:neufe...@php.net
 Summary:Segfault in filter_var with FILTER_VALIDATE_EMAIL
 with large amount of data
 Status: Closed
 Type:   Bug
 Package:Filter related
 PHP Version:5.3.3
 Assigned To:aharvey
 Block user comment: N

 New Comment:

The problem exists also in PHP 5.2.14.


Previous Comments:

[2010-09-28 15:14:59] neufe...@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 15:12:37] fel...@php.net

Hi, 5.2.x branch is in security bug fixes only. :)


[2010-09-28 15:03:26] support at hosting-agency dot de

This problem is also included in PHP version 5.2.14


[2010-09-27 09:08:13] ahar...@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-27 09:08:06] ahar...@php.net

Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=303779
Log: Fix bug #52929 (Segfault in filter_var with FILTER_VALIDATE_EMAIL
with large
amount of data).




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

http://bugs.php.net/bug.php?id=52929


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=52929edit=1


Bug #52929 [Com]: Segfault in filter_var with FILTER_VALIDATE_EMAIL with large amount of data

2010-09-27 Thread neufe...@php.net
Edit report at http://bugs.php.net/bug.php?id=52929edit=1

 ID: 52929
 Comment by: neufe...@php.net
 Reported by:neufe...@php.net
 Summary:Segfault in filter_var with FILTER_VALIDATE_EMAIL
 with large amount of data
 Status: Assigned
 Type:   Bug
 Package:Filter related
 PHP Version:5.3.3
 Assigned To:aharvey
 Block user comment: N

 New Comment:

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.


Previous Comments:

[2010-09-27 08:47:09] ahar...@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 07:24:16] ras...@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 05:21:50] ahar...@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 05:19:58] ahar...@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 02:38:06] neufe...@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.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

http://bugs.php.net/bug.php?id=52929


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=52929edit=1


Bug #52929 [Com]: Segfault in filter_var with FILTER_VALIDATE_EMAIL with large amount of data

2010-09-26 Thread neufe...@php.net
Edit report at http://bugs.php.net/bug.php?id=52929edit=1

 ID: 52929
 Comment by: neufe...@php.net
 Reported by:neufe...@php.net
 Summary:Segfault in filter_var with FILTER_VALIDATE_EMAIL
 with large amount of data
 Status: Open
 Type:   Bug
 Package:Unknown/Other Function
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

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.


Previous Comments:

[2010-09-27 02:09:24] neufe...@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 xx.data; done

Expected result:

bool(false)

Actual result:
--
segfault






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=52929edit=1