[PHP-BUG] Bug #60227 [NEW]: header() cannot detect the multi-line header with CR(0x0D).
From:
Operating system: Ubuntu Linux 11.10
PHP version: trunk-SVN-2011-11-06 (SVN)
Package: HTTP related
Bug Type: Bug
Bug description:header() cannot detect the multi-line header with CR(0x0D).
Description:
As of PHP 5.1.2, header() can no longer be used to send multiple response
headers
in a single call to prevent the HTTP Response Splitting Attack.
header() only checks the linefeed (LF, 0x0A) as line-end marker, it doesn't
check
the carriage-return (CR, 0x0D).
However, some browsers including Google Chrome, IE also recognize CR as the
line-
end (it is reported by Mr. Tokumaru).
The current specification of header() still has the vulnerability against
the
HTTP header splitting attack.
Test script:
---
?php
header('Location: '.$_GET['url']);
print_r($_COOKIE);
?
accessed from the url like:
http://example.com/head1.php?url=http://example.com/head1.php%0DSet-Cookie:+NAME=foo
It should be executed with Google Chrome or IE.
Expected result:
Warning: Header may not contain more than a single header, new line
detected. in
//head1.php on line 2
Array ( )
Actual result:
--
Array (NAME='foo')
--
Edit bug report at https://bugs.php.net/bug.php?id=60227edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60227r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60227r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60227r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60227r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60227r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60227r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60227r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60227r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60227r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60227r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60227r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60227r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60227r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60227r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60227r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60227r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60227r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60227r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60227r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60227r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60227r=mysqlcfg
[PHP-BUG] Bug #60229 [NEW]: From 1.3.8 GM version call to InitializeMagick required
From: Operating system: Linux PHP version: 5.3.8 Package: gmagick Bug Type: Bug Bug description:From 1.3.8 GM version call to InitializeMagick required Description: Please look at bugzilla bugreport from one of our user - https://bugzilla.redhat.com/show_bug.cgi?id=751376 -- Edit bug report at https://bugs.php.net/bug.php?id=60229edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60229r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60229r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60229r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60229r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60229r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60229r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60229r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60229r=needscript Try newer version: https://bugs.php.net/fix.php?id=60229r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60229r=support Expected behavior: https://bugs.php.net/fix.php?id=60229r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60229r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60229r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60229r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60229r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60229r=dst IIS Stability: https://bugs.php.net/fix.php?id=60229r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60229r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60229r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60229r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60229r=mysqlcfg
Bug #60227 [Opn-Csd]: header() cannot detect the multi-line header with CR(0x0D).
Edit report at https://bugs.php.net/bug.php?id=60227edit=1
ID: 60227
Updated by: hirok...@php.net
Reported by:rui_hirokawa at yahoo dot co dot jp
Summary:header() cannot detect the multi-line header with
CR(0x0D).
-Status: Open
+Status: Closed
Type: Bug
Package:HTTP related
Operating System: Ubuntu Linux 11.10
PHP Version:trunk-SVN-2011-11-06 (SVN)
-Assigned To:
+Assigned To:hirokawa
Block user comment: N
Private report: N
New Comment:
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2011-11-06 11:07:07] hirok...@php.net
Automatic comment from SVN on behalf of hirokawa
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=318820
Log: fixed bug #60227: header() cannot detect the multi-line header with CR.
[2011-11-06 07:04:50] rui_hirokawa at yahoo dot co dot jp
Description:
As of PHP 5.1.2, header() can no longer be used to send multiple response
headers
in a single call to prevent the HTTP Response Splitting Attack.
header() only checks the linefeed (LF, 0x0A) as line-end marker, it doesn't
check
the carriage-return (CR, 0x0D).
However, some browsers including Google Chrome, IE also recognize CR as the
line-
end (it is reported by Mr. Tokumaru).
The current specification of header() still has the vulnerability against the
HTTP header splitting attack.
Test script:
---
?php
header('Location: '.$_GET['url']);
print_r($_COOKIE);
?
accessed from the url like:
http://example.com/head1.php?url=http://example.com/head1.php%0DSet-Cookie:+NAME=foo
It should be executed with Google Chrome or IE.
Expected result:
Warning: Header may not contain more than a single header, new line detected.
in
//head1.php on line 2
Array ( )
Actual result:
--
Array (NAME='foo')
--
Edit this bug report at https://bugs.php.net/bug.php?id=60227edit=1
Bug #60226 [Opn-Csd]: segfault when calling setCAPath
Edit report at https://bugs.php.net/bug.php?id=60226edit=1
ID: 60226
Updated by: fel...@php.net
Reported by:glen at delfi dot ee
Summary:segfault when calling setCAPath
-Status: Open
+Status: Closed
Type: Bug
Package:oauth
Operating System: PLD Linux
PHP Version:5.3.8
-Assigned To:
+Assigned To:felipe
Block user comment: N
Private report: N
New Comment:
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2011-11-05 22:03:01] glen at delfi dot ee
Description:
$ cat tests/setCAPath.php
?php
$oauth = new OAuth('1', '2', OAUTH_SIG_METHOD_HMACSHA1, OAUTH_AUTH_TYPE_URI);
$o = $oauth-setCAPath('/etc/certs/ca-certificates.crt');
error_log(set path: $o);
this program causes segfault:
Program received signal SIGSEGV, Segmentation fault.
0x404d3afa in memcpy () from /lib/tls/libc.so.6
(gdb) bt
#0 0x404d3afa in memcpy () from /lib/tls/libc.so.6
#1 0x4018e635 in _estrndup () from /usr/lib/libphp_common-5.2.17.so
#2 0x41a9be2e in zim_oauth_setCAPath (ht=18, return_value=0x405b9628,
return_value_ptr=0x0, this_ptr=0x10, return_value_used=1, tsrm_ls=0x405bb0e8)
at /home/glen/rpm/pld/BUILD/php-pecl-oauth-1.2.2/oauth.c:2125
#3 0x401c80df in execute () from /usr/lib/libphp_common-5.2.17.so
#4 0x401c772c in execute () from /usr/lib/libphp_common-5.2.17.so
#5 0x401a9fe5 in zend_execute_scripts () from /usr/lib/libphp_common-5.2.17.so
#6 0x40162aa9 in php_execute_script () from /usr/lib/libphp_common-5.2.17.so
#7 0x0804b70d in main ()
(gdb)
--
Edit this bug report at https://bugs.php.net/bug.php?id=60226edit=1
Bug #60223 [Opn]: 5.4 and trunk segfaults when running the symfony2 testsuite
Edit report at https://bugs.php.net/bug.php?id=60223edit=1
ID: 60223
Updated by: fel...@php.net
Reported by:tyr...@php.net
Summary:5.4 and trunk segfaults when running the symfony2
testsuite
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: linux
PHP Version:5.4SVN-2011-11-05 (SVN)
Block user comment: N
Private report: N
New Comment:
Probably related to bug #60104
Previous Comments:
[2011-11-05 12:15:07] tyr...@php.net
Description:
5.4 and trunk segfaults running the testsuite:
http://ci.qa.php.net/view/php-userland/job/php-symfony2/75/label=debian-
amd64,phpversion=5.4/console
http://ci.qa.php.net/view/php-userland/job/php-symfony2/75/label=debian-
amd64,phpversion=trunk/console
while 5.3 runs the suite successfully:
http://ci.qa.php.net/view/php-userland/job/php-symfony2/75/label=debian-
amd64,phpversion=5.3/console
I rerun the command with --debug for phpunit, and the last test before the
segfault is
Symfony\Tests\Bridge\Doctrine\Form\Type\EntityTypeTest::testSubmitMultipleExpand
ed.
I rerun the test only for that test
class(Symfony\Tests\Bridge\Doctrine\Form\Type\EntityTypeTest), and it is
passing, no segfault.
The segfault also goes away, if I use --process-isolation for phpunit (will run
each test in a separate process, instead of running them in the same process
that is running phpunit), so it seems that there is no single snippet to
reproduce the error.
here is the backtrace from the coredump that I got:
#0 0x008cdef5 in ZEND_SEND_VAR_SPEC_CV_HANDLER
(execute_data=0x7f676823fa48) at /home/jenkins/workspace/php-src-5.4-matrix-
build/architecture/x86-64/os/linux-debian-6.0/Zend/zend_vm_execute.h:26859
26859ARG_SHOULD_BE_SENT_BY_REF(EX(fbc), opline-
op2.opline_num)) {
(gdb) bt
#0 0x008cdef5 in ZEND_SEND_VAR_SPEC_CV_HANDLER
(execute_data=0x7f676823fa48) at /home/jenkins/workspace/php-src-5.4-matrix-
build/architecture/x86-64/os/linux-debian-6.0/Zend/zend_vm_execute.h:26859
#1 0x007fcfa0 in execute (op_array=0x4d2b118) at
/home/jenkins/workspace/php-src-5.4-matrix-build/architecture/x86-64/os/linux-
debian-6.0/Zend/zend_vm_execute.h:410
#2 0x007be329 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/jenkins/workspace/php-src-5.4-matrix-
build/architecture/x86-64/os/linux-debian-6.0/Zend/zend.c:1272
#3 0x00731b6b in php_execute_script (primary_file=0x7fff101430b0) at
/home/jenkins/workspace/php-src-5.4-matrix-build/architecture/x86-64/os/linux-
debian-6.0/main/main.c:2414
#4 0x0090e88a in do_cli (argc=10, argv=0x7fff10143468) at
/home/jenkins/workspace/php-src-5.4-matrix-build/architecture/x86-64/os/linux-
debian-6.0/sapi/cli/php_cli.c:983
#5 0x0090f786 in main (argc=10, argv=0x7fff10143468) at
/home/jenkins/workspace/php-src-5.4-matrix-build/architecture/x86-64/os/linux-
debian-6.0/sapi/cli/php_cli.c:1356
if you need any help to further debug this, just ping me.
Test script:
---
git clone git://github.com/symfony/symfony.git;
cd symfony;
./PATH_TO_5.4_BINARY -d include_path=.:/usr/share/php:/usr/share/pear -d
date.timezone=UTC -d memory_limit=512M ./vendors.php;
./PATH_TO_5.4_BINARY -d include_path=.:/usr/share/php:/usr/share/pear -d
date.timezone=UTC -d memory_limit=512M /usr/bin/phpunit --log-junit=junit.xml;
Expected result:
no segfault
Actual result:
--
segfault
--
Edit this bug report at https://bugs.php.net/bug.php?id=60223edit=1
Req #55828 [Com]: Instantiation and call in one expression.
Edit report at https://bugs.php.net/bug.php?id=55828edit=1
ID: 55828
Comment by: php-dev at zerocue dot com
Reported by:connec dot 2002 at gmail dot com
Summary:Instantiation and call in one expression.
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Irrelevant
PHP Version:5.4.0beta1
Block user comment: N
Private report: N
New Comment:
There is an RFC documenting this request here:
https://wiki.php.net/rfc/instance-method-call
I believe one of the patches has been applied to the 5.4 branch per Felipe Pena
on 11/6/2011
Previous Comments:
[2011-10-04 18:21:00] mikko dot petteri dot hirvonen at gmail dot com
This feature is found on the 5.4 TODO list (https://wiki.php.net/todo/php54)
and
even a patch is available at https://wiki.php.net/rfc/instance-method-call, but
for reasons unknown it is not committed to 5.4 or even trunk.
[2011-10-04 18:10:15] design at oleku dot org
I totally agree ..
[2011-10-01 23:49:32] connec dot 2002 at gmail dot com
Description:
It would be nice if object instantiation and calling methods on the object
could
occur within the same expression.
Test script:
---
class A {
public function method() {
echo call\n;
}
}
new A(/* args, mayhaps */)-method();
new A-method();
Expected result:
call
call
Actual result:
--
Parse error: syntax error, unexpected '-'
--
Edit this bug report at https://bugs.php.net/bug.php?id=55828edit=1
Bug #48795 [Com]: Building intl 64-bit fails on OS X
Edit report at https://bugs.php.net/bug.php?id=48795edit=1 ID: 48795 Comment by: luke at cywh dot com Reported by:gwy...@php.net Summary:Building intl 64-bit fails on OS X Status: Verified Type: Bug Package:Compile Failure Operating System: Mac OS X 10.5.8, 10.6.2 PHP Version:5.3SVN-2009-11-23 (SVN) Block user comment: N Private report: N New Comment: Is there going to be a proper fix for this any time soon? I'm having a lot of trouble getting 5.3.8 to compile on OS X 10.6.8. Previous Comments: [2011-07-01 16:23:27] harald dot lapp at gmail dot com just setting the EXTRA_LIBS did not work for me, but stas tip made it work. (PHP 5.3.6, Mac OS X 10.6.7), thanks! [2010-06-17 19:43:39] henrik at bearwoods dot dk I have tried the above quick-fixes and have not been able to compile it yet. Im on a Macbook Pro i5 and 10.6.4 (Maybe the i5 makes a difference) [2010-05-24 21:19:51] s...@php.net Also if you change $(CC) to $(CXX) in BUILD_* vars in Makefile it seems to help too. Looks like if you use C++ anywhere in PHP the linker should be C++ or library should be added manually. I'll try to see if I can maybe make configure add needed magic juice there... [2010-04-20 19:31:52] fsb at thefeb dot org i confirm the fix [2010-02-10 12:05 UTC] surfchen at gmail dot com: add -lstdc++ into EXTRA_LIBS worked for 5.3.2 release on osx 10.6.3. [2010-02-10 14:05:58] surfchen at gmail dot com It is a linking problem, here is the simple workaround: edit Makefile and add -lstdc++ into EXTRA_LIBS. 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 https://bugs.php.net/bug.php?id=48795 -- Edit this bug report at https://bugs.php.net/bug.php?id=48795edit=1
Bug #18556 [Com]: Setting locale to 'tr_TR' lowercases class names
Edit report at https://bugs.php.net/bug.php?id=18556edit=1 ID: 18556 Comment by: gerd dot katzenbeisser at gmail dot com Reported by:spud at nothingness dot org Summary:Setting locale to 'tr_TR' lowercases class names Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Linux (RedHat 7.2) PHP Version:5CVS, 4CVS (2005-10-04) Assigned To:dmitry Block user comment: N Private report: N New Comment: here is a simple test case using the internal class PharFileInfo ? $class = 'PharFileInfo'; echo 'Locale: '.setlocale(LC_ALL, '0').\n; echo $class exists? .var_export(class_exists($class), true).\n; echo 'Locale: '.setlocale(LC_ALL, 'tr_TR.UTF-8').\n; echo $class exists? .var_export(class_exists($class), true); ? Output: Locale: C PharFileInfo exists? true Locale: tr_TR.UTF-8 PharFileInfo exists? false Previous Comments: [2011-09-16 14:18:21] robin dot bussiek at googlemail dot com @sweiss-at-stylesight thanks for your explanation. Big +1 for any solution to this topic. [2011-09-15 19:59:27] sweiss at stylesight dot com No, the problem results because lowercase i (in most languages) and uppercase I (in most languages) are not actually considered to be the upper/lower variant of the same letter in Turkish. In Turkish, the undotted ı is the lowercase of I, and the dotted İ is the uppercase of i. If you have a class named Image, it will break if the locale is changed to turkish because class_exists() function uses zend_str_tolower(), and changes the case on all classes, because they are supposed to be case insensitive. Someone else above explained it very well: class_exists() function uses zend_str_tolower(). zend_str_tolower() uses zend_tolower(). zend_tolower() uses _tolower_l() on Windows and tolower() on other oses. _tolower_l() is not locale aware. tolower() is LC_CTYPE aware. Please, oh please, can someone fix this already? It has been a very long time and it's extremely annoying and difficult to work around if you have a large multilingual website. [2011-09-15 19:51:48] robin dot bussiek at googlemail dot com I am sorry to ask this for my understanding: Is it true, that the cause for this bug lies in a false inclusion of the I character in the Turkish character set - and therefore results in an unnecessary replacement? If so, my green knowledge leads me to the assumption, that a fix should be rather simple. **duck**, Robin [2011-08-08 12:02:30] tolga at profelis dot com dot tr php -v PHP 5.3.3-7+squeeze3 with Suhosin-Patch (cli) (built: Jun 28 2011 08:24:40) Problem continues! [2010-08-28 12:14:34] web-coder at list dot ru Thanks to Alexey dot Rybak at gmail dot com for a patch, that fix problem if you use only ASCII-symbols in functions/methods names: http://dev.badoo.com/custom_strtolower.diff 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 https://bugs.php.net/bug.php?id=18556 -- Edit this bug report at https://bugs.php.net/bug.php?id=18556edit=1
Bug #35050 [Com]: Capital I letters in func/class method names do not work with turkish locale
Edit report at https://bugs.php.net/bug.php?id=35050edit=1 ID: 35050 Comment by: gerd dot katzenbeisser at gmail dot com Reported by:satanistlav at mail dot ru Summary:Capital I letters in func/class method names do not work with turkish locale Status: Wont fix Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5CVS-2005-11-01 (cvs) Block user comment: N Private report: N New Comment: This Bug is a duplicate of Bug #18556 Previous Comments: [2010-04-16 19:38:44] sweiss at stylesight dot com Requesting a fix for this... this has been going on for almost 5 years, yet the proper fix for the problem also only takes that many lines of code, according to a different bug report, which was rejected on a technicality. The workaround suggested means that none of my turkish is capitalized correctly. This is really not going over well. Please, please, please, at least make the fix listed in Bug #35050 an option that we can set in the php.ini or ideally with ini_set or *something*, if it causes problems for other programmers, and if it doesn't, can it just be fixed already? It is not going to be pretty when I have to go tell them that the turkish translation they've made is going to be permanently crippled until PHP 6 is released, and our code is updated to support it... and it looks like PHP 6 just went back to square one so this could be quite a long time. [2007-09-06 11:22:42] j...@php.net Patch by Tomas Kuliavas: http://www.topolis.lt/php/#35050 [2005-11-15 13:39:07] der...@php.net We discussed it and this will not be addressed in PHP 5, but only from PHP 6 and higher. Please make sure your set the correct locale before starting the script - or before including files that define elements that contain upper case I's. [2005-11-01 15:17:54] satanistlav at mail dot ru I have uploaded your code to the server and I still have the same error! http://www.yda.com.tr/test.php [2005-11-01 15:14:14] satanistlav at mail dot ru I have multilingual site. Locales are set to en_US.ISO-8859-1 in Enlgish side of the site and tr_TR.ISO-8859-9 in Turkish for LC_ALL 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 https://bugs.php.net/bug.php?id=35050 -- Edit this bug report at https://bugs.php.net/bug.php?id=35050edit=1
Bug #58979 [Com]: libtool: Version mismatch error
Edit report at https://bugs.php.net/bug.php?id=58979edit=1 ID: 58979 Comment by: sss at fsf dot ru Reported by:rebel29270 at orange dot fr Summary:libtool: Version mismatch error Status: Open Type: Bug Package:uploadprogress Operating System: gentoo PHP Version:5.2.11 Block user comment: N Private report: N New Comment: http://all-slotmachines.ru/ Previous Comments: [2011-11-06 23:25:32] sdsjdj at djnsj dot ru http://www.slotsbox.ru http://www.slotsbox.ru/free-slots.html http://all- slotmachines.ru/ [2011-11-05 00:26:40] aaasas at mail dot ru http://pokerblind.ru/ http://onhe.info/ http://slotbet.info/ http://fleurspetal.com/ http://www.smm2006.com [2011-09-17 21:34:04] info at lideli dot co dot jp http://www.pillspass.com/ priligy :-))) http://www.medicaservice.net/ prednisone 4277 [2011-09-15 21:50:43] SeiwaDnk at nirai dot ne dot jp http://www.yourpillshouse.com/ colchicine 8-[ http://www.pillsparadise.com/ valtrex 8-[ [2011-09-01 21:02:02] edit-gg at flute dot ocn dot ne dot jp http://www.mdmanager.net/ propecia 8((( http://www.lowpricedmeds.net/ prescription online consultation propecia govogs 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 https://bugs.php.net/bug.php?id=58979 -- Edit this bug report at https://bugs.php.net/bug.php?id=58979edit=1
