Bug #63520 [Asn-Nab]: JSON extension includes a problematic license statement
Edit report at https://bugs.php.net/bug.php?id=63520edit=1 ID: 63520 Updated by: ses...@php.net Reported by:kaplan at debian dot org Summary:JSON extension includes a problematic license statement -Status: Assigned +Status: Not a bug Type: Bug Package:JSON related PHP Version:Irrelevant Assigned To:remi -Block user comment: No +Block user comment: Yes Private report: N New Comment: Why do you guys even argue about this? This is not a problem of PHP. It is a problem of Debian. If they don't like the license then they can just replace the code. Or they can go forward and drop the whole PHP package from their distribution. (Which is the usual threat from Debian mainteiners.) Not a bug in PHP. Previous Comments: [2013-08-28 06:46:41] ond...@php.net Stas: Of course it's a PHP bug. PHP don't live in a vacuum, but has thriving ecosystem of various users/packagers/distributors/distributions/etc. and they are all affected by the choice you (as PHP) make. It's not healthy to dug the head into the sand and pretend that it's not a _PHP_ bug, since it affects the users of PHP. [2013-08-22 22:01:39] kap...@php.net Stas: We (PHP) provide the code, and the eco system clearly has a problem with it. We could either keep ignoring it while they provide a replacement code, or adopt it officially to make everyone happy. [2013-08-22 21:52:19] shitty at gmail dot com Not evil???... come on!!! [2013-08-21 18:47:57] s...@php.net How this is a PHP bug? [2013-07-17 15:18:33] r...@php.net @seld Mandriva/Fedora/Debian have drop json non-free extension but provides jsonc dropin alternative (php5-json 1.3.1 for debian). So, your comment is not PHP related. See debian packager to have this package installed when needed (pulled by main php package for Fedora). 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=63520 -- Edit this bug report at https://bugs.php.net/bug.php?id=63520edit=1
Bug #54547 [Nab]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547edit=1 ID: 54547 Updated by: ses...@php.net Reported by:peter dot ritt at gmx dot net Summary:wrong equality of string numbers Status: Not a bug Type: Bug Package:Unknown/Other Function Operating System: linux PHP Version:5.3.6 Assigned To:dmitry Block user comment: N Private report: N New Comment: This behaviour is for sure a bug. The == vs. === argument does not apply here. PHP should not perform the type conversion for the comparison if the result of the type conversion does not fit into the actual type converted to. Previous Comments: [2012-04-13 10:15:52] yohg...@php.net Just a comment for users who would like to use large numbers. There are bcmath and gmp modules for large number arithmetic. [2012-04-13 07:08:00] paj...@php.net ok, enough arguing. There is no bug here. [2012-04-13 03:13:57] four dot zero dot one dot unauthorized at gmail dot com This behavior is documented here: http://php.net/manual/en/language.operators.comparison.php If you compare a number with a string or the comparison involves numerical strings, then each string is converted to a number and the comparison performed numerically. These rules also apply to the switch statement. The type conversion does not take place when the comparison is === or !== as this involves comparing the type as well as the value. Shouldn't this feature of converting numerical strings to numbers during loose comparison operations between two strings be dropped? If a developer wanted to compare values given during POST or GET processing AS numbers, they should cast the inputs to (int) or (float) first. There really should be a fundamental shift away from catering to developer laziness, and force developers to pay more attention to variable and input handling on their own. [2012-04-13 01:10:44] the dot matt dot kantor at gmail dot com @hholzgra: Your only-coerce-on-failure proposal would not solve this issue. Assuming that by fail you mean the comparison evaluates to false, the strings would end up being coerced anyway (since they are indeed different), they'd become identical floats, and things would be the same as they are now. If I misunderstood what you meant by fail, then we'd lose 1 == 1.0, which I don't think is something that can (or should) happen. [2012-04-12 22:45:28] erowid at inbox dot lv I want to marry it, lather this thread up, and have my way with it. I want to have little threads everywhere that are as funny as this xD 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=54547 -- Edit this bug report at https://bugs.php.net/bug.php?id=54547edit=1
Bug #60990 [Opn]: Segfault when trying to allocate more memory
Edit report at https://bugs.php.net/bug.php?id=60990edit=1 ID: 60990 Updated by: ses...@php.net Reported by:flatline at hardwired dot hu Summary:Segfault when trying to allocate more memory Status: Open Type: Bug Package:FPM related Operating System: Debian Squeeze x86_64 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: I don't know what you mean under Do you have NO PHP code running on the system? I just wanted to know how this crash happens: a) one specific PHP file b) nearly all files c) by just requesting any file (in case of C the most obvious reason would be some extension being compiled in a different way than PHP itself - Debian e.g. for a long time compiled their PHP with LFS support, but forgot to set this flag in PHP-DEV so all compiled extensions had different struct sizes for some structs. And this caused crashes e.g. in Suhosin.so) Previous Comments: [2012-02-07 07:42:31] s...@php.net Full backtrace (or even better, a run under valgrind if it's reproduceable) would be helpful. I'd also recommend trying without suhosin.so just to ensure the problem is not there (second trace still shows it loading). From the trace it looks like the fault is in _zval_ptr_dtor which doesn't look like segfault as a result of allocator returning null - the argument is not null and _zval_ptr_dtor is not usually called right after allocator. Does it also crash if you set envt variable USE_ZEND_MM to 0 (that turns off Zend MM)? [2012-02-06 18:05:12] flatline at hardwired dot hu When I remove the suhosin.so extension it still segfaults. I don't know what you mean under Do you have NO PHP code running on the system?. It's a quite complex script, but I can reproduce the problem each and every time. If I'm not mistaken when Zend tries to allocate some more memory and it bumps into the memory_limit parameter, it blindly uses the resulting (NULL) pointer, so that causes this segfault. Here is the new backtrace, without suhosin.so loaded, with the env parameter you suggested: gdb /usr/sbin/php5-fpm ./core-fpm GNU gdb (GDB) 7.0.1-debian Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/sbin/php5-fpm...Reading symbols from /usr/lib/debug/usr/sbin/php5-fpm...done. (no debugging symbols found)...done. warning: Can't read pathname for load map: Input/output error. Reading symbols from /lib/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /usr/lib/libonig.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libonig.so.2 Reading symbols from /usr/lib/libcrypto.so.0.9.8...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libcrypto.so.0.9.8 Reading symbols from /usr/lib/libssl.so.0.9.8...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libssl.so.0.9.8 Reading symbols from /usr/lib/libdb-4.8.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libdb-4.8.so Reading symbols from /usr/lib/libqdbm.so.14...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libqdbm.so.14 Reading symbols from /lib/libbz2.so.1.0...(no debugging symbols found)...done. Loaded symbols for /lib/libbz2.so.1.0 Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/librt.so.1 Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /usr/lib/libgssapi_krb5.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgssapi_krb5.so.2 Reading symbols from /usr/lib/libkrb5.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libkrb5.so.3 Reading symbols from /usr/lib/libk5crypto.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libk5crypto.so.3 Reading symbols from /lib/libcom_err.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libcom_err.so.2 Reading symbols from /usr/lib/libxml2.so.2...(no
Req #60655 [Opn]: add max_input_vars for json/serialize
Edit report at https://bugs.php.net/bug.php?id=60655edit=1 ID: 60655 Updated by: ses...@php.net Reported by:larue...@php.net Summary:add max_input_vars for json/serialize Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.9RC4 Block user comment: N Private report: N New Comment: Your patch does not fix the problem. It will make the first X hashtable grow operations random. But the moment you already inserte 65536 entries the HashTable is now big enough to launch the attack. Maybe your test script already breaks your patch the moment you try to insert 2^17 entries. Otherwise the attack script might need some tweaking. Anyway, your patch will not solve the problem. Previous Comments: [2012-01-05 08:09:18] larue...@php.net The following patch has been added/updated: Patch Name: rand_hash_resize.patch Revision: 1325750958 URL: https://bugs.php.net/patch-display.php?bug=60655patch=rand_hash_resize.patchrevision=1325750958 [2012-01-05 05:04:53] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739893 URL: https://bugs.php.net/patch-display.php?bug=60655patch=max_input_vars.patchrevision=1325739893 [2012-01-05 05:03:29] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739809 URL: https://bugs.php.net/patch-display.php?bug=60655patch=max_input_vars.patchrevision=1325739809 [2012-01-05 05:02:16] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739736 URL: https://bugs.php.net/patch-display.php?bug=60655patch=max_input_vars.patchrevision=1325739736 [2012-01-05 04:17:03] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325737023 URL: https://bugs.php.net/patch-display.php?bug=60655patch=max_input_vars.patchrevision=1325737023 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=60655 -- Edit this bug report at https://bugs.php.net/bug.php?id=60655edit=1
Req #60655 [Opn]: add max_input_vars for json/serialize
Edit report at https://bugs.php.net/bug.php?id=60655edit=1 ID: 60655 Updated by: ses...@php.net Reported by:larue...@php.net Summary:add max_input_vars for json/serialize Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.9RC4 Block user comment: N Private report: N New Comment: You are mistaken to believe that randomizing the TableSize will stop predictable collisions: This is only true if you try to exploit the problem with numerical indicies. The moment you use alpha numerical keys and produce collisions in the DJB hashing function the table size does not matter anymore, because the return value of the hash function is the same. Previous Comments: [2012-01-05 11:29:15] larue...@php.net sorry, didn't get your point? the collision can not be predicatible any more, why this patch doesn't solve the problem? [2012-01-05 11:24:44] ses...@php.net Your patch does not fix the problem. It will make the first X hashtable grow operations random. But the moment you already inserte 65536 entries the HashTable is now big enough to launch the attack. Maybe your test script already breaks your patch the moment you try to insert 2^17 entries. Otherwise the attack script might need some tweaking. Anyway, your patch will not solve the problem. [2012-01-05 08:09:18] larue...@php.net The following patch has been added/updated: Patch Name: rand_hash_resize.patch Revision: 1325750958 URL: https://bugs.php.net/patch-display.php?bug=60655patch=rand_hash_resize.patchrevision=1325750958 [2012-01-05 05:04:53] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739893 URL: https://bugs.php.net/patch-display.php?bug=60655patch=max_input_vars.patchrevision=1325739893 [2012-01-05 05:03:29] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739809 URL: https://bugs.php.net/patch-display.php?bug=60655patch=max_input_vars.patchrevision=1325739809 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=60655 -- Edit this bug report at https://bugs.php.net/bug.php?id=60655edit=1
Req #60655 [Opn]: add max_input_vars for json/serialize
Edit report at https://bugs.php.net/bug.php?id=60655edit=1 ID: 60655 Updated by: ses...@php.net Reported by:larue...@php.net Summary:add max_input_vars for json/serialize Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.9RC4 Block user comment: N Private report: N New Comment: It is not a theory, The whole disclosure from n-runs was about colliding the DJB hash function with alpha numerical keys. Previous Comments: [2012-01-05 14:14:08] larue...@php.net laruence I got you point, and agree in theory, yes, the string hash value could be the same, does anyone have a method to compute it in real? nikic yes laruence I really doubt that if we can find so many string keys with the same hash value to be able launch a attach, and won't reach the max post size [2012-01-05 14:05:52] larue...@php.net oh, I got you, thanks. [2012-01-05 14:04:50] larue...@php.net yes, the hash value of string index is the same, but the index = hash_value % nTableSize, we don't use the hash value as index directly, didn't I misunderstand you? [2012-01-05 11:53:37] ses...@php.net You are mistaken to believe that randomizing the TableSize will stop predictable collisions: This is only true if you try to exploit the problem with numerical indicies. The moment you use alpha numerical keys and produce collisions in the DJB hashing function the table size does not matter anymore, because the return value of the hash function is the same. [2012-01-05 11:29:15] larue...@php.net sorry, didn't get your point? the collision can not be predicatible any more, why this patch doesn't solve the problem? 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=60655 -- Edit this bug report at https://bugs.php.net/bug.php?id=60655edit=1
Req #60655 [Opn]: add max_input_vars for json/serialize
Edit report at https://bugs.php.net/bug.php?id=60655edit=1 ID: 60655 Updated by: ses...@php.net Reported by:larue...@php.net Summary:add max_input_vars for json/serialize Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.9RC4 Block user comment: N Private report: N New Comment: BTW a simple approach to cause 65536 alpha numerical collisions would use most probably less than 2MB of POST payload. And this is the NOT mathematically optimized version. Previous Comments: [2012-01-05 14:47:21] larue...@php.net sesser, I am not good at algorithm, so if you can help me, I will appreciate. just a guess, what about change the zend_hash_func, add some new seed like: register ulong hash = 5381 + nKeyLength; thanks [2012-01-05 14:44:32] ses...@php.net It is not a theory, The whole disclosure from n-runs was about colliding the DJB hash function with alpha numerical keys. [2012-01-05 14:14:08] larue...@php.net laruence I got you point, and agree in theory, yes, the string hash value could be the same, does anyone have a method to compute it in real? nikic yes laruence I really doubt that if we can find so many string keys with the same hash value to be able launch a attach, and won't reach the max post size [2012-01-05 14:05:52] larue...@php.net oh, I got you, thanks. [2012-01-05 14:04:50] larue...@php.net yes, the hash value of string index is the same, but the index = hash_value % nTableSize, we don't use the hash value as index directly, didn't I misunderstand you? 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=60655 -- Edit this bug report at https://bugs.php.net/bug.php?id=60655edit=1
Req #60655 [Opn]: add max_input_vars for json/serialize
Edit report at https://bugs.php.net/bug.php?id=60655edit=1 ID: 60655 Updated by: ses...@php.net Reported by:larue...@php.net Summary:add max_input_vars for json/serialize Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.9RC4 Block user comment: N Private report: N New Comment: laruence: nothing against you, but fixing the hash table thing is not a simple easy fix. It must be done by someone who understands the mathematical problem of hash collisions and who understands the impact of making changes to a hash function. Just changing some constants in the algorithm will not improve the situation. The opposite can be the case. By changing some constants it could be possible to destroy the distribution of collisions and suddenly some values collide more often than others. So please do not try to fix a problem that must be solved by someone with the mathematical background knowledge. Previous Comments: [2012-01-05 14:48:14] ses...@php.net BTW a simple approach to cause 65536 alpha numerical collisions would use most probably less than 2MB of POST payload. And this is the NOT mathematically optimized version. [2012-01-05 14:47:21] larue...@php.net sesser, I am not good at algorithm, so if you can help me, I will appreciate. just a guess, what about change the zend_hash_func, add some new seed like: register ulong hash = 5381 + nKeyLength; thanks [2012-01-05 14:44:32] ses...@php.net It is not a theory, The whole disclosure from n-runs was about colliding the DJB hash function with alpha numerical keys. [2012-01-05 14:14:08] larue...@php.net laruence I got you point, and agree in theory, yes, the string hash value could be the same, does anyone have a method to compute it in real? nikic yes laruence I really doubt that if we can find so many string keys with the same hash value to be able launch a attach, and won't reach the max post size [2012-01-05 14:05:52] larue...@php.net oh, I got you, thanks. 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=60655 -- Edit this bug report at https://bugs.php.net/bug.php?id=60655edit=1
#42826 [Csd-Opn]: Random problem with accessing file by php runtime
ID: 42826 Updated by: [EMAIL PROTECTED] Reported By: lahcim at fajne dot com -Status: Closed +Status: Open Bug Type: Apache related Operating System: FreeBSD 6.2-STABLE PHP Version: 5.2.4 New Comment: I am reopening this bug because it is nonsense that this bug is caused by the Suhosin Patch. It is more likely that some 64 bit issue in PHP exists that is hidden by some obscure struct size but when Suhosin is activated it is suddenly visible. Previous Comments: [2007-10-02 12:31:21] lahcim at fajne dot com I removed the suhoshin patch. Currently running on: PHP 5.2.4 (cli) (built: Oct 2 2007 14:20:20) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies It seems that the bug is fixed. I am closing the bug. I will reopen if it starts to happen with the current configuration, but it seems that the suhoshin patch caused the problem. [2007-10-02 11:14:03] [EMAIL PROTECTED] First of all get rid of any 3rd party patches / extensions / zend extension in your PHP build, such as any optimizers, caches and that suhosin patch. [2007-10-02 10:21:25] lahcim at fajne dot com Description: I found similar bug here: #41476 It is exactly the same problem. Randomly I am getting error: Warning: Unknown: failed to open stream: No such file or directory in Unknown on line 0 Fatal error: Unknown: Failed opening required '/home/www/main/wybranski.com/wybranski.com/data/photos/2006.04 FoodExplorer/slides/IMG_0366.html' (include_path='.:/usr/local/share/pear') in Unknown on line 0 While the path is 100% correct and the file exists! After refreshing the same webpage it works. You can see that I have associated also .html files to be parsed as php but it also happens for pure php files. I remove the php.ini completly, so it runs with default configuration. The only extensions I have are: extension=gd.so extension=imap.so extension=mysql.so extension=ldap.so but the bug also happens when there are no extensions loaded, so it is php apache module bug. I could not repro this bug on CLI, it happens only with apache module. Reproduce code: --- It seems that it happens on this particular configuration: PHP 5.2.4 with Suhosin-Patch 0.9.6.2 (cli) (built: Oct 2 2007 12:01:40) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies Server version: Apache/1.3.37 (Unix) Server built: Sep 24 2007 20:07:19 FreeBSD plustech.pl 6.2-STABLE FreeBSD 6.2-STABLE #1: Mon Aug 20 14:53:07 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GTT amd64 I have the same configuration on a different server, but on x86 machine and the problem does NOT happen on x86. It seems that it can be a bug with php apache module compiled for amd64 architecture in particulary. The bug happens randomly. I do not know on which it depends. To experience the bug please go to: http://www.wybranski.com/photos/ and start reviewing the pictures one after another. After some time the error will appear. Than after refreshing the same webpage it will be all ok. But than when you continue reviewing other pages the bug will happen again. Expected result: The page that the bug is reporting as Failed opening required exists! So it should load it without saying that it has a problem. Actual result: -- It reports 'Failed opening required' error on a file that is present and available: Warning: Unknown: failed to open stream: No such file or directory in Unknown on line 0 Fatal error: Unknown: Failed opening required '/home/www/main/wybranski.com/wybranski.com/data/photos/2006.04 FoodExplorer/slides/IMG_0366.html' (include_path='.:/usr/local/share/pear') in Unknown on line 0 (I enabled php for .html extensions but it also work /the bug happens also/ for pure .php files) -- Edit this bug report at http://bugs.php.net/?id=42826edit=1
#40148 [Opn]: Segfault when pspell extension is enabled
ID: 40148 Updated by: [EMAIL PROTECTED] Reported By: rick at gibbed dot us Status: Open Bug Type: Pspell related Operating System: FreeBSD 6.1 PHP Version: 5.2.0 New Comment: This actually seems to be FreeBSD Loader bug. For no obvious reason sometimes some extensions (especially pspell.so) crash on unload. In some cases it can be fixed by just moving the crashing extension to the front or to the end of your extension.ini. The real reason for this is however unknown. But it only seems to happen on FreeBSD. Previous Comments: [2007-01-16 18:31:23] rick at gibbed dot us Description: PHP install from scratch causes crash on exit when pspell extension is loaded. A similar bugreport can be found at http://bugs.php.net/bug.php?id=40007 which was disregarded because of a zend extension. Reproduce code: --- php -v Actual result: -- PHP 5.2.0 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 16 2007 12:00:18) Copyright (c) 1997-2006 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies Segmentation fault: 11 (core dumped) gdb /usr/local/bin/php php.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd...(no debugging symbols found)... Core was generated by `php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libcrypt.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.3 Reading symbols from /lib/libm.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.4 Reading symbols from /usr/local/lib/libxml2.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxml2.so.5 Reading symbols from /lib/libz.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.3 Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /usr/local/lib/php/20060613/session.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/php/20060613/session.so Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x28ff1ea8 in __do_global_dtors_aux () from /usr/local/lib/php/20060613/session.so #2 0x28ff9078 in _fini () from /usr/local/lib/php/20060613/session.so #3 0x28274018 in tls_dtv_generation () from /libexec/ld-elf.so.1 #4 0x282753d8 in ?? () from /libexec/ld-elf.so.1 #5 0xbfbfe818 in ?? () #6 0x2825c08e in elf_hash () from /libexec/ld-elf.so.1 #7 0x2825e970 in dlclose () from /libexec/ld-elf.so.1 #8 0x0815e40d in zend_hash_apply_deleter () #9 0x0815e49c in zend_hash_graceful_reverse_destroy () #10 0x08153f7f in zend_shutdown () #11 0x08116852 in php_module_shutdown () #12 0x081d7544 in main () (gdb) where full #0 0x in ?? () No symbol table info available. #1 0x28ff1ea8 in __do_global_dtors_aux () from /usr/local/lib/php/20060613/session.so No symbol table info available. #2 0x28ff9078 in _fini () from /usr/local/lib/php/20060613/session.so No symbol table info available. #3 0x28274018 in tls_dtv_generation () from /libexec/ld-elf.so.1 No symbol table info available. #4 0x282753d8 in ?? () from /libexec/ld-elf.so.1 No symbol table info available. #5 0xbfbfe818 in ?? () No symbol table info available. #6 0x2825c08e in elf_hash () from /libexec/ld-elf.so.1 No symbol table info available. #7 0x2825e970 in dlclose () from /libexec/ld-elf.so.1 No symbol table info available. #8 0x0815e40d in zend_hash_apply_deleter () No symbol table info available. #9 0x0815e49c in zend_hash_graceful_reverse_destroy () No symbol table info available. #10 0x08153f7f in zend_shutdown () No symbol table info available. #11 0x08116852 in php_module_shutdown () No symbol table info available. #12 0x081d7544 in main () No symbol table info available. -- Edit this bug report at http://bugs.php.net/?id=40148edit=1
#40148 [Opn-Fbk]: Segfault when pspell extension is enabled
ID: 40148 Updated by: [EMAIL PROTECTED] Reported By: rick at gibbed dot us -Status: Open +Status: Feedback Bug Type: Pspell related Operating System: FreeBSD 6.1 PHP Version: 5.2.0 Previous Comments: [2007-01-16 18:53:01] [EMAIL PROTECTED] This actually seems to be FreeBSD Loader bug. For no obvious reason sometimes some extensions (especially pspell.so) crash on unload. In some cases it can be fixed by just moving the crashing extension to the front or to the end of your extension.ini. The real reason for this is however unknown. But it only seems to happen on FreeBSD. [2007-01-16 18:31:23] rick at gibbed dot us Description: PHP install from scratch causes crash on exit when pspell extension is loaded. A similar bugreport can be found at http://bugs.php.net/bug.php?id=40007 which was disregarded because of a zend extension. Reproduce code: --- php -v Actual result: -- PHP 5.2.0 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 16 2007 12:00:18) Copyright (c) 1997-2006 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies Segmentation fault: 11 (core dumped) gdb /usr/local/bin/php php.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd...(no debugging symbols found)... Core was generated by `php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libcrypt.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.3 Reading symbols from /lib/libm.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.4 Reading symbols from /usr/local/lib/libxml2.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxml2.so.5 Reading symbols from /lib/libz.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.3 Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /usr/local/lib/php/20060613/session.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/php/20060613/session.so Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x28ff1ea8 in __do_global_dtors_aux () from /usr/local/lib/php/20060613/session.so #2 0x28ff9078 in _fini () from /usr/local/lib/php/20060613/session.so #3 0x28274018 in tls_dtv_generation () from /libexec/ld-elf.so.1 #4 0x282753d8 in ?? () from /libexec/ld-elf.so.1 #5 0xbfbfe818 in ?? () #6 0x2825c08e in elf_hash () from /libexec/ld-elf.so.1 #7 0x2825e970 in dlclose () from /libexec/ld-elf.so.1 #8 0x0815e40d in zend_hash_apply_deleter () #9 0x0815e49c in zend_hash_graceful_reverse_destroy () #10 0x08153f7f in zend_shutdown () #11 0x08116852 in php_module_shutdown () #12 0x081d7544 in main () (gdb) where full #0 0x in ?? () No symbol table info available. #1 0x28ff1ea8 in __do_global_dtors_aux () from /usr/local/lib/php/20060613/session.so No symbol table info available. #2 0x28ff9078 in _fini () from /usr/local/lib/php/20060613/session.so No symbol table info available. #3 0x28274018 in tls_dtv_generation () from /libexec/ld-elf.so.1 No symbol table info available. #4 0x282753d8 in ?? () from /libexec/ld-elf.so.1 No symbol table info available. #5 0xbfbfe818 in ?? () No symbol table info available. #6 0x2825c08e in elf_hash () from /libexec/ld-elf.so.1 No symbol table info available. #7 0x2825e970 in dlclose () from /libexec/ld-elf.so.1 No symbol table info available. #8 0x0815e40d in zend_hash_apply_deleter () No symbol table info available. #9 0x0815e49c in zend_hash_graceful_reverse_destroy () No symbol table info available. #10 0x08153f7f in zend_shutdown () No symbol table info available. #11 0x08116852 in php_module_shutdown () No symbol table info available. #12 0x081d7544 in main () No symbol table info available. -- Edit this bug report at http://bugs.php.net/?id=40148edit=1
#38915 [Opn-Bgs]: mod_php: system() (and similar) don't cleanup opened handles of Apache
ID: 38915
Updated by: [EMAIL PROTECTED]
Reported By: dimmoborgir at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Apache2 related
Operating System: UNIX
PHP Version: 4.4.3, 4.4.4, 5.0.4, 5.1.4, 5.1.6, 5.2.0RC5
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
The opened file descriptors are opened by Apache.
It is the job of Apache to protect them, not something that should be
reinvented in all apache modules.
Not a bug in PHP.
Previous Comments:
[2006-09-24 18:17:22] dimmoborgir at gmail dot com
Tested on versions 4.4.3, 4.4.4, 5.0.4, 5.1.4, 5.1.6, 5.2.0RC5.
[2006-09-21 19:15:25] dimmoborgir at gmail dot com
Description:
The problem is in exec, system, popen (and similar) PHP functions. The
fact is that PHP doesn't sanitize opened file descriptors before
executing a program.
These functions use popen() C function to spawn a program.
popen() is equal to the successive execution of
pipe(), fork(), dup2(), exec().
These functions keep all opened handles. (Except STDOUT, which is
replaced to pipe).
This bug makes php-includes vulnerabilities more dangerous.
If the server uses mod_php, and we can execute shell commands via
system(), then we can, e.g. stop apache processes (by sending a
SIGSTOP), and to listen and process connections on 80 port (opened by
Apache, and transmitted to us by PHP). Also we can write anything to
its errorlog.
Reproduce code:
---
Some steps to reproduce a bug.
First. Simple program to wait :)
# cat test1.c
int main()
{
setsid( );
sleep( 1 );
}
#gcc -o test1 test1.c
Ok. Let's make a php script:
#cat a.php
?php
system( ./test1 );
?
Request: http://127.0.0.1/a.php
Good. Now see opened handles:
#lsof | grep test1
test1 cwdDIR /usr/local/apache2/htdocs
test1 rtdDIR /
test1 txtREG /var/www/html/test1
test1 memREG /lib/tls/libc-2.3.5.so
test1 memREG /lib/ld-2.3.5.so
test1 memREG [stack] (stat: No such file or
directory)
test1 0r CHR /dev/null
test1 1w FIFO pipe
test1 2w REG /usr/local/apache2/logs/error_log
test1 3u IPv4 *:http (LISTEN)
test1 4r FIFO pipe
test1 5w FIFO pipe
test1 6w REG /usr/local/apache2/logs/error_log
test1 7w REG /usr/local/apache2/logs/access_log
test1 8r unknown inode type
test1 9u IPv4 10.0.0.2:http-10.0.0.1:2134
(CLOSE_WAIT)
So, our test1 has apache's handles. Now we can do something like that:
int p = getsid( 0 ); // get current Process Group Id
setsid( ); // become session leader
kill( -p, SIGSTOP ); // good night, Apache Process Group :)
And after that:
for ( sock = 3; sock getdtablesize(); sock++ ) // find valid socket
handle
if ( listen (sock, 10) == 0 ) break;
Full exploit is available on http://hackerdom.ru/~dimmo/phpexpl.c
Expected result:
I didn't expected program, executed via system() PHP function, to have
all opened descriptors of Apache Web Server (including 80 port, error
and access logs, opened connections, etc...)
Actual result:
--
Our PHP program has all descriptors of Apache Server.
--
Edit this bug report at http://bugs.php.net/?id=38915edit=1
#38762 [Asn-Opn]: build dir != src dir results in Zend/zend_language_parser.c: No such file
ID: 38762 Updated by: [EMAIL PROTECTED] Reported By: butterblume83 at gmx dot de -Status: Assigned +Status: Open Bug Type: Compile Failure Operating System: Ubuntu Dapper Drake PHP Version: 5.1.6 Assigned To: sesser New Comment: The flex check works. The behaviour introduced with PHP 5.2 was unwanted. The original reporter reported the issue with PHP 5.1.6 which is proof enough, that my change that is only in 5.2 is NOT responsible. Previous Comments: [2006-09-09 21:38:58] [EMAIL PROTECTED] Stefan, your change broke the check for flex: http://cvs.php.net/viewvc.cgi/php-src/acinclude.m4?r1=1.332.2.14.2.1r2=1.332.2.14.2.2 [2006-09-09 21:27:25] butterblume83 at gmx dot de It works after I downgraded flex (2.5.31-38) to flex-old (2.5.4a-7). Please edit php's configure script so that a fatal error is thrown if the flex version is invalid. [2006-09-09 21:13:51] [EMAIL PROTECTED] Can't reproduce. [2006-09-09 20:35:08] butterblume83 at gmx dot de Is the configure-line: checking for flex version... invalid interesting? [2006-09-09 20:31:50] butterblume83 at gmx dot de @tony2001: does not help. 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/38762 -- Edit this bug report at http://bugs.php.net/?id=38762edit=1
#38525 [Fbk-Ctl]: 5.2.0RC2 + squirrelmail == random segfaults , heap corruption
ID: 38525
Updated by: [EMAIL PROTECTED]
Reported By: judas dot iscariote at gmail dot com
-Status: Feedback
+Status: Critical
Bug Type: Reproducible crash
Operating System: linux
PHP Version: 5.2.0RC2
New Comment:
Obviously the new heap implementation from Zend is unstable.
Previous Comments:
[2006-08-21 08:39:58] [EMAIL PROTECTED]
Could you also please try to see if valgrind tells you anything?
valgrind --tool=memcheck --log-file=httpd /path/to/apache/httpd -X
And check out httpd.PID file.
[2006-08-20 20:27:50] judas dot iscariote at gmail dot com
update summary.
[2006-08-20 19:00:21] judas dot iscariote at gmail dot com
#1 0x2af677a1970e in zend_mm_panic (message=0x2af677b5ade9 Heap
corrupted)
at /local/local/bodegon/php-debug/Zend/zend_alloc.c:61
No locals.
#2 0x2af677a19c00 in zend_mm_remove_from_free_list
(heap=0x55867130, mm_block=0x2af679814fc0)
at /local/local/bodegon/php-debug/Zend/zend_alloc.c:473
prev = (zend_mm_free_block *) 0x55867268
next = (zend_mm_free_block *) 0x3631f6792bdbc8
#3 0x2af677a1c39a in _zend_mm_realloc_int (heap=0x55867130,
p=0x2af6797d5060, size=262104,
__zend_filename=0x2af677b3bb78
/local/local/bodegon/php-debug/ext/standard/var.c,
__zend_lineno=531,
__zend_orig_filename=0x0, __zend_orig_lineno=0) at
/local/local/bodegon/php-debug/Zend/zend_alloc.c:1450
mm_block = (zend_mm_block *) 0x2af6797d5020
next_block = (zend_mm_block *) 0x2af679814fc0
true_size = 262176
ptr = (void *) 0x23a8
#4 0x2af677a1cae6 in _erealloc (ptr=0x2af6797d5060, size=262104,
allow_failure=0,
__zend_filename=0x2af677b3bb78
/local/local/bodegon/php-debug/ext/standard/var.c,
__zend_lineno=531,
__zend_orig_filename=0x0, __zend_orig_lineno=0) at
/local/local/bodegon/php-debug/Zend/zend_alloc.c:1633
No locals.
#5 0x2af6779a8e47 in php_var_serialize_long (buf=0x7fff362aa7a0,
val=407)
at /local/local/bodegon/php-debug/ext/standard/var.c:531
__nl = 261975
__dest = (smart_str *) 0x7fff362aa7a0
#6 0x2af6779a84f0 in php_var_serialize_intern (buf=0x7fff362aa7a0,
struc=0x2af678c00088, var_hash=0x7fff362aa750)
at /local/local/bodegon/php-debug/ext/standard/var.c:807
key = 0x2af6785dc9c0 hililist
data = (zval **) 0x2af6787d9060
key_len = 9
index = 407
pos = (HashPosition) 0x2af6787d8e40
incomplete_class = 0 '\0'
i = 2
var_already = (ulong *) 0x55867268
myht = (HashTable *) 0x2af6791b4710
#7 0x2af6779a9326 in php_var_serialize (buf=0x7fff362aa7a0,
struc=0x2af678c00088, var_hash=0x7fff362aa750)
at /local/local/bodegon/php-debug/ext/standard/var.c:845
No locals.
#8 0x2af6778ad8d5 in ps_srlzr_encode_php (newstr=0x7fff362aa808,
newlen=0x7fff362aa82c)
at /local/local/bodegon/php-debug/ext/session/session.c:479
_ht = (HashTable *) 0x2af6785592d0
---Type return to continue, or q return to quit---
buf = {
c = 0x2af6797d5060
gettext_php_loaded|b:0;gettext_php_domain|s:0:\\;gettext_php_dir|s:0:\\;gettext_php_translateStrings|a:0:{}gettext_php_loaded_language|s:0:\\;gettext_php_short_circuit|b:0;sq_base_url|s:27:\http://hel;...,
len = 261973,
a = 262103}
var_hash = {nTableSize = 16384, nTableMask = 16383,
nNumOfElements = 8427, nNextFreeElement = 988,
pInternalPointer = 0x2af678f40f08, pListHead = 0x2af678f40f08,
pListTail = 0x2af6794865f0, arBuckets = 0x2af6791b4f48,
pDestructor = 0, persistent = 0 '\0', nApplyCount = 0 '\0',
bApplyProtection = 1 '\001', inconsistent = 0}
key = 0x2af678c000b0 msgs
key_length = 4
num_key = 47238021375260
struc = (zval **) 0x2af678c00088
#9 0x2af6778ae43d in php_session_encode (newlen=0x7fff362aa82c)
at /local/local/bodegon/php-debug/ext/session/session.c:581
ret = 0x0
#10 0x2af6778aefb2 in php_session_save_current_state () at
/local/local/bodegon/php-debug/ext/session/session.c:860
val = 0x3 Address 0x3 out of bounds
vallen = 0
ret = -1
#11 0x2af6778b3f3d in php_session_flush () at
/local/local/bodegon/php-debug/ext/session/session.c:1845
orig_bailout = (jmp_buf *) 0x7fff362aa9c0
bailout = {{__jmpbuf = {160, -72001594702856356,
93824996795000, 93824995284840, 93824993674584, 93824993672000,
-72001594702856596, -71943351702066904}, __mask_was_saved = 0,
__saved_mask = {__val = {47238068320056, 0,
47238068320144, 88, 2840945349788, 47238058731560,
47238060414864, 140734102153504, 88, 140734102153536,
47238057413229, 140734102153536, 0, 0, 3017073977613,
47238058478808
#12 0x2af6778b3f86 in zm_deactivate_session (type=1,
#35978 [Fbk]: %n format string specifier wrongly implemented
ID: 35978
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Reproducible crash
Operating System: irrelevant
PHP Version: 6CVS-2006-01-12 (CVS)
Assigned To: helly
New Comment:
To reproduce this you need to write a PHP extension, because the
problem is in our spprintf/snprintf functions. You could try something
like
spprintf(blah%n, x);
It should crash, because when %n is parsed it will write 4 to x and
then try to output what currently is within s and has the length s_len.
Because s_len is not initialised it will try to output a random number
of bytes stored at NULL. When %n is found it has to overjump the whole
output process.
You don't need a backtrace: it will crash in
static void xbuf_format_converter(smart_str *xbuf, const char *fmt,
va_list ap)
{
when it tries todo
/*
* Print the string s.
*/
INS_STRING(xbuf, s, s_len);
at the end of the function. Because s and s_len are not properly
initialised. %n should atleast set s_len to 0 if not overjump the
output step completely.
Previous Comments:
[2006-01-12 14:22:50] [EMAIL PROTECTED]
Reproduce case and gdb backtrace are highly welcome.
[2006-01-12 14:12:32] [EMAIL PROTECTED]
Description:
%n is wrongly implemented in our low level printf functions.
When %n is used, it does not only write the char counter but also
agains outputs whatever is in the current string buffer. = crash when
%n is used first.
--
Edit this bug report at http://bugs.php.net/?id=35978edit=1
#35170 [Opn-Ctl]: PHP_AUTH_DIGEST differs under Apache 1.x and 2.x
ID: 35170
Updated by: [EMAIL PROTECTED]
Reported By: lacak at users dot sourceforge dot net
-Status: Open
+Status: Critical
-Bug Type: Feature/Change Request
+Bug Type: Apache2 related
Operating System: Windows
PHP Version: 5.1.0RC4
New Comment:
Advertised new features should actually work.
Previous Comments:
[2005-11-09 13:20:59] lacak at users dot sourceforge dot net
Description:
PHP_AUTH_DIGEST differs under Apache 1.x and 2.x
Apache 1.x:
_SERVER[PHP_AUTH_DIGEST]='username=user1, realm=www.realm.sk-0,
qop=auth, algorithm=MD5, uri=/devel/php_auth.php, nonce=nonce,
nc=0001, cnonce=11a85ba98273fe0f5578597b1dbf3082,
opaque=opaque, response=088685b1533e542920e1c47b59696b9c';
Apache 2.x:
_SERVER[PHP_AUTH_DIGEST]='Digest username=cd,
realm=www.realm.sk, nonce=nonce, uri=/~cb/php_auth.php,
response=bedf1a35418a3712adc0aea22e94d9f2, opaque=opaque, qop=auth,
nc=0001, cnonce=082c875dcb2ca740';
Under Apache 2.x the word Digest is at the begining. Under Apache
1.x is not.
Resolution:
1. strip out leading Digest from PHP_AUTH_DIGEST in Apache 2.x
2. or add Digest at the begining PHP_AUTH_DIGEST in Apache 1.x (but
is redundant)
3. or the best solution is change PHP_AUTH_DIGEST to associative array
(parse string and build array elements from it; similar way how cookies
are parsed) :
(Otherwise this step must be always done in php script)
PHP_AUTH_DIGEST[username]=user1;
PHP_AUTH_DIGEST[realm]=www.realm.sk-0;
...
This is example in PHP how to convert PHP_AUTH_DIGEST string to array
:
foreach(explode(, , $_SERVER[PHP_AUTH_DIGEST] as $auth1) {
list($authkey,$authvalue)=explode(=,$auth1,2);
if (substr($authvalue,0,1)=='' substr($authvalue,-1,1)=='')
$authvalue=substr($authvalue,1,-1); /*strip out double quotes*/
$auth[$authkey]=$authvalue;
}
/* at this point $auth array contains what we need */
Please incorporate this feature to php source code.
Thank you very much for your time and effort.
Laco.
--
Edit this bug report at http://bugs.php.net/?id=35170edit=1
#34734 [Asn-Bgs]: Bugfix #32827 is incorrect
ID: 34734 Updated by: [EMAIL PROTECTED] Reported By: gustav at cst dot co dot za -Status: Assigned +Status: Bogus Bug Type: *General Issues Operating System: Windows Server 2003 PHP Version: 4.4.0 Assigned To: sesser New Comment: Version 1 Cookies are not suppoted by PHP Therefore whatever RFC 2965 says is irrelevant If you want version 1 cookie support, then add a feature request Previous Comments: [2005-10-04 18:27:58] [EMAIL PROTECTED] Stefan, you had a patch ready? :) [2005-10-04 17:38:51] gustav at cst dot co dot za Description: This bug was classified Won't fix before, because according to [EMAIL PROTECTED], it would not be backwards compatible with the netscape cookie specification. See a href=http://bugs.php.net/bug.php?id=32827;#32827/a for details. However, [EMAIL PROTECTED]'s interpretation of the netscape cookie standard is incompatible with the HTTP protocol specification and the HTTP State Management Mechanism specification. Backwards compatability in this case breaks more than it fixes. See a href=http://bugs.php.net/bug.php?id=32966;#32966/a and a href=http://bugs.php.net/bug.php?id=32111;#32111/a for details. The problem I encountered is the same as #32966. I get two Cookie: headers which are then combined into one by seperating them with a comma. This breaks the session id. Now my motivation for why cookies *must* be allowed to be comma seperated: In both the HTTP/1.0 and HTTP/1.1 protocol specifications (RFCs 1945 and 2068) it is stated in section 4.2 (Message Headers) that: Multiple HTTP-header fields with the same field-name may be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It must be possible to combine the multiple header fields into one field- name: field-value pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. Also, in the HTTP State Management Mechanism specification (RFC 2965) section 3.3.4 (Sending Cookies to the Origin Server) defines the syntax of the cookie header as: cookie = Cookie: cookie-version 1*((; | ,) cookie-value) Thereby showing that plain commas imply a seperate cookie. Reproduce code: --- Using a raw telnet session to IIS running PHP: GET / HTTP/1.0 Host: myhost.somewhere.com Cookie: PHPSESSID=6664337de02c5bad6c175e0bb3c10a45 Cookie: $Version=1; id=8; Expected result: No error. Actual result: -- session_start(): The session id contains invalid characters, valid characters are only a-z, A-Z and 0-9 -- Edit this bug report at http://bugs.php.net/?id=34734edit=1
#32850 [NoF-Csd]: PHP crashes on startup because zend_do_implement_interface is called with NULL
ID: 32850 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Closed Bug Type: SQLite related Operating System: Debian Sarge Unstable PHP Version: 5CVS-2005-04-27 (dev) New Comment: using gawk fixes the extension load order problem Previous Comments: [2005-05-07 01:00:04] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2005-04-29 16:36:20] [EMAIL PROTECTED] Well yeah it does not crash for me on other systems, too... But it crashes on a more or less fresh install of Debian Sarge Unstable. And the configure line does not matter... Same behaviour with ./configure --with-apxs=... ./configure ./configure bunch of options I have really no clue why it dies on that one system, because I have nothing unusual on it... (But I will look into it again tonight...) [2005-04-29 02:25:58] [EMAIL PROTECTED] It doesn't crash for me (either, as I guess it didn't for Antony?). So..start with the configure line you used? :) [2005-04-28 22:46:11] [EMAIL PROTECTED] PHP crashes in the second I invoke ./php Like the backtrace shows it dies when loading sqlite extension because it ends up calling zend_do_implement_interface (ce=0x82f2ca0, iface=0x0) --- with a 0x0 NULL pointer [2005-04-28 22:00:13] [EMAIL PROTECTED] Any info on how to reproduce it? 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/32850 -- Edit this bug report at http://bugs.php.net/?id=32850edit=1
#32943 [Opn-Bgs]: is_numeric validates 3e0
ID: 32943
Updated by: [EMAIL PROTECTED]
Reported By: pmorgan at ukds dot net
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 4.3.10
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
3e0 is a number in e-notation, which is of course a numerical string
Previous Comments:
[2005-05-04 12:29:00] pmorgan at ukds dot net
typo
[2005-05-04 12:28:04] pmorgan at ukds dot net
Description:
With some server side validation I inadvertenly entered 3e0 into the
textbox, it validated to my suprise. Would have expected this to throw
a false
Reproduce code:
---
echo is_numeric('3e00')? 'true': 'false';
Expected result:
false;
In fact anything without 0-9 and a . I would expect a false !
--
Edit this bug report at http://bugs.php.net/?id=32943edit=1
#32850 [Fbk]: PHP crashes on startup because zend_do_implement_interface is called with NULL
ID: 32850
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: SQLite related
Operating System: Debian Sarge Unstable
PHP Version: 5CVS-2005-04-27 (dev)
New Comment:
Well yeah it does not crash for me on other systems, too...
But it crashes on a more or less fresh install of Debian Sarge
Unstable.
And the configure line does not matter... Same behaviour with
./configure --with-apxs=...
./configure
./configure bunch of options
I have really no clue why it dies on that one system, because I have
nothing unusual on it...
(But I will look into it again tonight...)
Previous Comments:
[2005-04-29 02:25:58] [EMAIL PROTECTED]
It doesn't crash for me (either, as I guess it didn't for Antony?).
So..start with the configure line you used? :)
[2005-04-28 22:46:11] [EMAIL PROTECTED]
PHP crashes in the second I invoke ./php
Like the backtrace shows it dies when loading sqlite extension because
it ends up calling zend_do_implement_interface (ce=0x82f2ca0,
iface=0x0) --- with a 0x0 NULL pointer
[2005-04-28 22:00:13] [EMAIL PROTECTED]
Any info on how to reproduce it?
[2005-04-27 12:04:51] [EMAIL PROTECTED]
Description:
#0 zend_hash_merge_ex (target=0x82f2d38, source=0x98,
pCopyConstructor=0x81d6e10 zval_add_ref, size=4,
pMergeSource=0x81c8ec0 do_inherit_constant_check, pParam=0x0) at
/home/.../php5-200504251230/Zend/zend_hash.c:818
p = (Bucket *) 0x82f2ca0
t = (void *) 0x82f4908
#1 0x081c8f79 in zend_do_implement_interface (ce=0x82f2ca0,
iface=0x0)
at /home/.../php5-200504251230/Zend/zend_compile.c:2099
No locals.
#2 0x081dbfa9 in zend_class_implements (class_entry=0x82f2ca0,
num_interfaces=2)
at /home/.../php5-200504251230/Zend/zend_API.c:1646
interface_entry = (zend_class_entry *) 0x98
ce_num = 2
impl_num = 2
interface_list = 0xb390 è#@ ¦/@\214
#3 0x080f6102 in zm_startup_sqlite (type=1, module_number=4) at
/home/.../php5-200504251230/ext/sqlite/sqlite.c:1024
No locals.
#4 0x081daf38 in zend_register_module_ex (module=0x82f0028) at
/home/.../php5-200504251230/Zend/zend_API.c:1227
lcname = 0x0
module_ptr = (zend_module_entry *) 0x82f0028
#5 0x081a0dc0 in php_startup_extensions (ptr=0x82a450c, count=152) at
/home/.../php5-200504251230/main/main.c:1269
end = (zend_module_entry **) 0x82a453c
#6 0x08246d2b in php_startup_internal_extensions () at
main/internal_functions_cli.c:72
No locals.
#7 0x081a13ea in php_module_startup (sf=0x828396c,
additional_modules=0x0, num_additional_modules=152)
at /home/.../php5-200504251230/main/main.c:1454
zuf = {error_function = 0x819fbb0 php_error_cb,
printf_function = 0x819f510 php_printf,
write_function = 0x81a0d70 php_body_write_wrapper, fopen_function =
0x81a0220 php_fopen_wrapper_for_zend,
message_handler = 0x81a0340 php_message_handler_for_zend,
block_interruptions = 0, unblock_interruptions = 0,
get_configuration_directive = 0x81a02f0
php_get_configuration_directive_for_zend,
ticks_function = 0x81abd60 php_run_ticks, on_timeout =
0x81a0480 php_on_timeout,
stream_open_function = 0x81a0270 php_stream_open_for_zend,
vspprintf_function = 0x81a42c0 vspprintf,
getenv_function = 0x81a7620 sapi_getenv}
zuv = {import_use_extension = 0x82576e6 .php,
import_use_extension_length = 136766146, html_errors = 1 '\001'}
#8 0x08245c9e in main (argc=1, argv=0xbbd4) at
/home/.../php5-200504251230/sapi/cli/php_cli.c:632
exit_status = 0
c = 152
file_handle = {type = 0 '\0', filename = 0x82a46f4
[EMAIL PROTECTED],
opened_path = 0xbb28 Hûÿ¿Ûs$\bÜûÿ¿`\234/@, handle = {fd =
134697609, fp = 0x8075289, stream = {handle = 0x8075289,
reader = 0x402f9c50 sys_sigabbrev+25040, closer = 0xbb34,
interactive = -1073743032}}, free_filename = 219 'Û'}
--
Edit this bug report at http://bugs.php.net/?id=32850edit=1
#32860 [Opn]: quoted-string cookies not handled correctly
ID: 32860 Updated by: [EMAIL PROTECTED] Reported By: ast at gmx dot ch Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: 4.3.11 New Comment: You are wrong. It is not a bug. PHP implements Cookie version 0 which is based upon the Netscape Cookie standard. Both RFCs 2109/2965 speak of Cookie version 1. Previous Comments: [2005-04-28 12:03:44] ast at gmx dot ch But even the initial cookie RFC, http://rfc.net/rfc2109.html, described that a value may be either a TOKEN or a quoted-string. The only difference to the new cookie RFC, RFC 2965, is that are not allowed in quoted-string values of the old version while they may be in quoted-string values, just escaped by the escape character \ in the new version. Therefore, the separaters , and ; are allowed in quoted-string values even in the old cookie RFC. Maybe you could list it as a low-priority bug, but it's a bug and not a feature or a change request. [2005-04-28 08:16:09] [EMAIL PROTECTED] When PHP was written, this RFC did not yet exist - that's why we classify it as a feature request - it's basically cookie version 1.1. [2005-04-28 00:04:15] ast at gmx dot ch Feature/Change request? I don't agree. Handling a HTTP header not according to the RFCs they are defined in doesn't make sense at all. Therefore, it's a bug. But it's not that important to me. Do what you consider the right thing. [2005-04-28 00:00:18] [EMAIL PROTECTED] Reclassified. [2005-04-27 23:20:34] ast at gmx dot ch Obviously, the bug report was mangled. Here's a pretty print of the report / fix: http://nei.ch/articles/quoted_string_cookie_fix.php 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/32860 -- Edit this bug report at http://bugs.php.net/?id=32860edit=1
#32860 [Opn]: quoted-string cookies not handled correctly
ID: 32860 Updated by: [EMAIL PROTECTED] Reported By: ast at gmx dot ch Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: 4.3.11 New Comment: You claimed that PHP handles quoted-strings within cookies incorrectly. This is simply wrong. PHP supports version 0 cookies, like all browsers do by default and there are no quoted-strings in the version 0 standard. It doesn't matter when the Cookie Version 1 RFCs were released. Fact is: the web uses mainly version 0 cookies. So Jani was right when he changed this into a feature request. Previous Comments: [2005-04-28 15:41:08] ast at gmx dot ch Fact is that PHP 2 was released after RFC 2109 and the dev cycle of PHP 3, 4, and 5 started completely after RFC 2109 was published. Interpret the issue as you want. I just wanted to help you to be more standards compliant. [2005-04-28 14:40:05] [EMAIL PROTECTED] You are wrong. It is not a bug. PHP implements Cookie version 0 which is based upon the Netscape Cookie standard. Both RFCs 2109/2965 speak of Cookie version 1. [2005-04-28 12:03:44] ast at gmx dot ch But even the initial cookie RFC, http://rfc.net/rfc2109.html, described that a value may be either a TOKEN or a quoted-string. The only difference to the new cookie RFC, RFC 2965, is that are not allowed in quoted-string values of the old version while they may be in quoted-string values, just escaped by the escape character \ in the new version. Therefore, the separaters , and ; are allowed in quoted-string values even in the old cookie RFC. Maybe you could list it as a low-priority bug, but it's a bug and not a feature or a change request. [2005-04-28 08:16:09] [EMAIL PROTECTED] When PHP was written, this RFC did not yet exist - that's why we classify it as a feature request - it's basically cookie version 1.1. [2005-04-28 00:04:15] ast at gmx dot ch Feature/Change request? I don't agree. Handling a HTTP header not according to the RFCs they are defined in doesn't make sense at all. Therefore, it's a bug. But it's not that important to me. Do what you consider the right thing. 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/32860 -- Edit this bug report at http://bugs.php.net/?id=32860edit=1
#32850 [Fbk]: PHP crashes on startup because zend_do_implement_interface is called with NULL
ID: 32850
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: SQLite related
Operating System: Debian Sarge Unstable
PHP Version: 5CVS-2005-04-27 (dev)
New Comment:
PHP crashes in the second I invoke ./php
Like the backtrace shows it dies when loading sqlite extension because
it ends up calling zend_do_implement_interface (ce=0x82f2ca0,
iface=0x0) --- with a 0x0 NULL pointer
Previous Comments:
[2005-04-28 22:00:13] [EMAIL PROTECTED]
Any info on how to reproduce it?
[2005-04-27 12:04:51] [EMAIL PROTECTED]
Description:
#0 zend_hash_merge_ex (target=0x82f2d38, source=0x98,
pCopyConstructor=0x81d6e10 zval_add_ref, size=4,
pMergeSource=0x81c8ec0 do_inherit_constant_check, pParam=0x0) at
/home/.../php5-200504251230/Zend/zend_hash.c:818
p = (Bucket *) 0x82f2ca0
t = (void *) 0x82f4908
#1 0x081c8f79 in zend_do_implement_interface (ce=0x82f2ca0,
iface=0x0)
at /home/.../php5-200504251230/Zend/zend_compile.c:2099
No locals.
#2 0x081dbfa9 in zend_class_implements (class_entry=0x82f2ca0,
num_interfaces=2)
at /home/.../php5-200504251230/Zend/zend_API.c:1646
interface_entry = (zend_class_entry *) 0x98
ce_num = 2
impl_num = 2
interface_list = 0xb390 è#@ ¦/@\214
#3 0x080f6102 in zm_startup_sqlite (type=1, module_number=4) at
/home/.../php5-200504251230/ext/sqlite/sqlite.c:1024
No locals.
#4 0x081daf38 in zend_register_module_ex (module=0x82f0028) at
/home/.../php5-200504251230/Zend/zend_API.c:1227
lcname = 0x0
module_ptr = (zend_module_entry *) 0x82f0028
#5 0x081a0dc0 in php_startup_extensions (ptr=0x82a450c, count=152) at
/home/.../php5-200504251230/main/main.c:1269
end = (zend_module_entry **) 0x82a453c
#6 0x08246d2b in php_startup_internal_extensions () at
main/internal_functions_cli.c:72
No locals.
#7 0x081a13ea in php_module_startup (sf=0x828396c,
additional_modules=0x0, num_additional_modules=152)
at /home/.../php5-200504251230/main/main.c:1454
zuf = {error_function = 0x819fbb0 php_error_cb,
printf_function = 0x819f510 php_printf,
write_function = 0x81a0d70 php_body_write_wrapper, fopen_function =
0x81a0220 php_fopen_wrapper_for_zend,
message_handler = 0x81a0340 php_message_handler_for_zend,
block_interruptions = 0, unblock_interruptions = 0,
get_configuration_directive = 0x81a02f0
php_get_configuration_directive_for_zend,
ticks_function = 0x81abd60 php_run_ticks, on_timeout =
0x81a0480 php_on_timeout,
stream_open_function = 0x81a0270 php_stream_open_for_zend,
vspprintf_function = 0x81a42c0 vspprintf,
getenv_function = 0x81a7620 sapi_getenv}
zuv = {import_use_extension = 0x82576e6 .php,
import_use_extension_length = 136766146, html_errors = 1 '\001'}
#8 0x08245c9e in main (argc=1, argv=0xbbd4) at
/home/.../php5-200504251230/sapi/cli/php_cli.c:632
exit_status = 0
c = 152
file_handle = {type = 0 '\0', filename = 0x82a46f4
[EMAIL PROTECTED],
opened_path = 0xbb28 Hûÿ¿Ûs$\bÜûÿ¿`\234/@, handle = {fd =
134697609, fp = 0x8075289, stream = {handle = 0x8075289,
reader = 0x402f9c50 sys_sigabbrev+25040, closer = 0xbb34,
interactive = -1073743032}}, free_filename = 219 'Û'}
--
Edit this bug report at http://bugs.php.net/?id=32850edit=1
#32850 [Opn-Ctl]: sesser
ID: 32850
Updated by: [EMAIL PROTECTED]
-Summary: PHP crashes on startup because
zend_do_implement_interface is called with NULL
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Critical
Bug Type: SQLite related
Operating System: Debian Sarge Unstable
PHP Version: 5CVS-2005-04-27 (dev)
Previous Comments:
[2005-04-27 12:04:51] [EMAIL PROTECTED]
Description:
#0 zend_hash_merge_ex (target=0x82f2d38, source=0x98,
pCopyConstructor=0x81d6e10 zval_add_ref, size=4,
pMergeSource=0x81c8ec0 do_inherit_constant_check, pParam=0x0) at
/home/.../php5-200504251230/Zend/zend_hash.c:818
p = (Bucket *) 0x82f2ca0
t = (void *) 0x82f4908
#1 0x081c8f79 in zend_do_implement_interface (ce=0x82f2ca0,
iface=0x0)
at /home/.../php5-200504251230/Zend/zend_compile.c:2099
No locals.
#2 0x081dbfa9 in zend_class_implements (class_entry=0x82f2ca0,
num_interfaces=2)
at /home/.../php5-200504251230/Zend/zend_API.c:1646
interface_entry = (zend_class_entry *) 0x98
ce_num = 2
impl_num = 2
interface_list = 0xb390 è#@ ¦/@\214
#3 0x080f6102 in zm_startup_sqlite (type=1, module_number=4) at
/home/.../php5-200504251230/ext/sqlite/sqlite.c:1024
No locals.
#4 0x081daf38 in zend_register_module_ex (module=0x82f0028) at
/home/.../php5-200504251230/Zend/zend_API.c:1227
lcname = 0x0
module_ptr = (zend_module_entry *) 0x82f0028
#5 0x081a0dc0 in php_startup_extensions (ptr=0x82a450c, count=152) at
/home/.../php5-200504251230/main/main.c:1269
end = (zend_module_entry **) 0x82a453c
#6 0x08246d2b in php_startup_internal_extensions () at
main/internal_functions_cli.c:72
No locals.
#7 0x081a13ea in php_module_startup (sf=0x828396c,
additional_modules=0x0, num_additional_modules=152)
at /home/.../php5-200504251230/main/main.c:1454
zuf = {error_function = 0x819fbb0 php_error_cb,
printf_function = 0x819f510 php_printf,
write_function = 0x81a0d70 php_body_write_wrapper, fopen_function =
0x81a0220 php_fopen_wrapper_for_zend,
message_handler = 0x81a0340 php_message_handler_for_zend,
block_interruptions = 0, unblock_interruptions = 0,
get_configuration_directive = 0x81a02f0
php_get_configuration_directive_for_zend,
ticks_function = 0x81abd60 php_run_ticks, on_timeout =
0x81a0480 php_on_timeout,
stream_open_function = 0x81a0270 php_stream_open_for_zend,
vspprintf_function = 0x81a42c0 vspprintf,
getenv_function = 0x81a7620 sapi_getenv}
zuv = {import_use_extension = 0x82576e6 .php,
import_use_extension_length = 136766146, html_errors = 1 '\001'}
#8 0x08245c9e in main (argc=1, argv=0xbbd4) at
/home/.../php5-200504251230/sapi/cli/php_cli.c:632
exit_status = 0
c = 152
file_handle = {type = 0 '\0', filename = 0x82a46f4
[EMAIL PROTECTED],
opened_path = 0xbb28 Hûÿ¿Ûs$\bÜûÿ¿`\234/@, handle = {fd =
134697609, fp = 0x8075289, stream = {handle = 0x8075289,
reader = 0x402f9c50 sys_sigabbrev+25040, closer = 0xbb34,
interactive = -1073743032}}, free_filename = 219 'Û'}
--
Edit this bug report at http://bugs.php.net/?id=32850edit=1
#32836 [Opn-Csd]: sesser
ID: 32836 Updated by: [EMAIL PROTECTED] -Summary: security bug Reported By: kkrusteff at intergenia dot de -Status: Open +Status: Closed Bug Type: Unknown/Other Function Operating System: linux PHP Version: 4.3.10 New Comment: This is not a bug in PHP but in glibc realpath() If you are unable to strip ../ from your user input, then either report this as bug in realpath() to the glibc folks or simply change your OS to a bsd. (Or use the hardening patch from the hardened-php project ;) Previous Comments: [2005-04-27 09:06:55] kkrusteff at intergenia dot de No matter what you call it or verify your inputs, it's a BUG. In no other language / shell / usual program in unix/linux you can do such thing and to be accepted as valid file! This file does NOT actually exists. Why including it results in getting wrong file?. Wrong parsing in include() function? Yes, no doubt. Please don't tell people 'verify your inputs'. Sometimes it's not possible. Or they should execute 'readlink -f ' before including? or do other weird stuff to avoid this case. Or what? [2005-04-27 04:46:58] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Validate your inputs. [2005-04-26 15:53:31] slavi at imperia dot net See #29949 Relative include() sometimes works as expected. ( http://bugs.php.net/bug.php?id=29949 ) I think it describes the same problem. [2005-04-26 13:58:31] kkrusteff at intergenia dot de Description: Frequently used way to include lang file include(./lang/login.php.$_REQUEST[lang]); The problem is if in URL use lang=../../../../../../../../../../etc/hosts and we get the host file from computer. Reproduce code: --- ?PHP include(./lang/login.php.../../../../../../../../../../etc/hosts); ? //or ?php include(./lang/login.php.../../../../../../../../../etc/hosts); ? //that's will show the host file Expected result: file not found Actual result: -- that's will show the host file or other file .. if you know the path -- Edit this bug report at http://bugs.php.net/?id=32836edit=1
#32836 [Csd]: security bug
ID: 32836 Updated by: [EMAIL PROTECTED] -Summary: sesser Reported By: kkrusteff at intergenia dot de Status: Closed Bug Type: Unknown/Other Function Operating System: linux PHP Version: 4.3.10 New Comment: wtf Previous Comments: [2005-04-27 12:11:09] [EMAIL PROTECTED] This is not a bug in PHP but in glibc realpath() If you are unable to strip ../ from your user input, then either report this as bug in realpath() to the glibc folks or simply change your OS to a bsd. (Or use the hardening patch from the hardened-php project ;) [2005-04-27 09:06:55] kkrusteff at intergenia dot de No matter what you call it or verify your inputs, it's a BUG. In no other language / shell / usual program in unix/linux you can do such thing and to be accepted as valid file! This file does NOT actually exists. Why including it results in getting wrong file?. Wrong parsing in include() function? Yes, no doubt. Please don't tell people 'verify your inputs'. Sometimes it's not possible. Or they should execute 'readlink -f ' before including? or do other weird stuff to avoid this case. Or what? [2005-04-27 04:46:58] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Validate your inputs. [2005-04-26 15:53:31] slavi at imperia dot net See #29949 Relative include() sometimes works as expected. ( http://bugs.php.net/bug.php?id=29949 ) I think it describes the same problem. [2005-04-26 13:58:31] kkrusteff at intergenia dot de Description: Frequently used way to include lang file include(./lang/login.php.$_REQUEST[lang]); The problem is if in URL use lang=../../../../../../../../../../etc/hosts and we get the host file from computer. Reproduce code: --- ?PHP include(./lang/login.php.../../../../../../../../../../etc/hosts); ? //or ?php include(./lang/login.php.../../../../../../../../../etc/hosts); ? //that's will show the host file Expected result: file not found Actual result: -- that's will show the host file or other file .. if you know the path -- Edit this bug report at http://bugs.php.net/?id=32836edit=1
#31442 [Asn-Fbk]: unserialize broken on 64-bit systems
ID: 31442 Updated by: [EMAIL PROTECTED] Reported By: michal at cihar dot com -Status: Assigned +Status: Feedback Bug Type: Zend Engine 2 problem Operating System: 64-bit PHP Version: 4.3.10, 5.0.3 Assigned To: helly New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip This should be fixed since 17. January in CVS Previous Comments: [2005-03-07 15:21:38] michal at cihar dot com The patch works fine also on 5.0.3, I have no idea what could break tests for you... [2005-01-08 20:00:53] michal at cihar dot com I can't reproduce these failures here (php 4.3.10). [2005-01-08 18:39:07] [EMAIL PROTECTED] php run-tests.php ext/standard/tests/serialize ... FAILED TEST SUMMARY - serialize()/unserialize()/var_dump() [ext/standard/tests/serialize/001.phpt] Bug #25378 (unserialize() crashes with invalid data) [ext/standard/tests/serialize/002.phpt] Bug #14293 (serialize() and __sleep()) [ext/standard/tests/serialize/bug14293.phpt] Bug #21957 (serialize() mangles objects with __sleep) [ext/standard/tests/serialize/bug21957.phpt] Bug #25378 (unserialize() crashes with invalid data) [ext/standard/tests/serialize/bug25378.phpt] Bug #28325 (Problem in serialisation of circular references) [ext/standard/tests/serialize/bug28325.phpt] [2005-01-08 18:32:38] michal at cihar dot com What kind of tests do fail? I have no idea what could be broken by this change. [2005-01-08 14:41:01] [EMAIL PROTECTED] If i apply that patch to a 32 bit machine i get many test errors any idea? Also it is enough to put the .re 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 http://bugs.php.net/31442 -- Edit this bug report at http://bugs.php.net/?id=31442edit=1
#32627 [Csd]: realpath fails to return FALSE if last path component does not exist
ID: 32627
Updated by: [EMAIL PROTECTED]
Reported By: alan dot harder at sun dot com
Status: Closed
Bug Type: Filesystem function related
Operating System: FreeBSD 4.11-STABLE
PHP Version: 4.3.10
New Comment:
This is not fixed at all...
This is a documentation bug...
realpath() uses the underlying system realpath() { unless you run it
with the hardening-patch }
On linux/glibc realpath() will return failure if the last component
does not exist.
On BSD realpath() will not return failure if only the last component
does not exist.
Previous Comments:
[2005-04-07 21:42:39] alan dot harder at sun dot com
thanks for the response. by latest do you mean php5? as shown in
this bug description I tested with today's stable 4.3.x build in
addition to 4.3.10 where i found the problem.
[2005-04-07 21:04:46] [EMAIL PROTECTED]
Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at
http://www.php.net/downloads.php
[2005-04-07 18:23:45] alan dot harder at sun dot com
Description:
I have found that realpath() returns a path when it should return FALSE
if only the last path component in the given string does not exist.
Tested on php 4.3.10 and php4-STABLE-200504071438. Both tests and
phpinfo can be viewed at http://realpath.moshpit.org/
Reproduce code:
---
$x = realpath('/bad/path'); var_dump($x);
$x = realpath('/badpath'); var_dump($x);
$x = realpath('/tmp/badpath'); var_dump($x);
View tests at http://realpath.moshpit.org/
Expected result:
FALSE for all three tests.
Actual result:
--
The first one works (gets FALSE), the other two return the path when
they should return FALSE (assuming /tmp is valid).
--
Edit this bug report at http://bugs.php.net/?id=32627edit=1
#31723 [Bgs]: call function_exists in safe_mod return true to set_time_limit
ID: 31723
Updated by: [EMAIL PROTECTED]
Reported By: diogo at netmake dot com dot br
Status: Bogus
Bug Type: *General Issues
Operating System: Any System
PHP Version: 4.3.10
New Comment:
The function still exists in safe_mode it is just not allowed. You have
to check if safe_mode is enabled or not instead.
Previous Comments:
[2005-01-27 17:40:48] [EMAIL PROTECTED]
The function exists, which is why the return value of function_exists
is TRUE.
[2005-01-27 15:32:42] diogo at netmake dot com dot br
Description:
I'm doing a multiplataform software. I always need to set
set_time_limit(0), but some unix disable then turning on safe_mode. in
safe_mode, some functions and functionales are disabled. how can call
function_exists(set_time_limit) to test if always i get TRUE? in
safe_mode should be false. The same happens with get_defined_functions,
that returns an array with set_time_limit seted TRUE.
Reproduce code:
---
$bol_result = function_exists(set_time_limit);
if($bol_result)
{
set_time_limit(0);
}
Expected result:
$bol_result return false
Actual result:
--
$bol_result returns true, then call set_time_limit, my php is in
safe_mode so crash:
set_time_limit(): Cannot set time limit in safe mode
--
Edit this bug report at http://bugs.php.net/?id=31723edit=1
#31704 [Fbk]: pointer error in var_unserializer.c?
ID: 31704 Updated by: [EMAIL PROTECTED] Reported By: frode at coretrek dot no Status: Feedback Bug Type: Strings related Operating System: FreeBSD 4.10 PHP Version: 4.3.10 New Comment: The code is correct in that area. If you are using sessions your segfault could be cause because FreeBSD does not use http://cvs.php.net/diff.php/php-src/ext/session/session.c?r1=1.336.2.48r2=1.336.2.49ty=u without this fix it is possible that the rearrangement of unserialize() triggers the bug in the session module. If this does not fix the problem please give a full backtrace. Because even if the code segfaults in unserialize() the crash could be cause because it was previously called in an not 100% correct way. Previous Comments: [2005-01-26 17:22:29] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2005-01-26 16:38:18] frode at coretrek dot no Description: I've been having problems with php segfaulting randomly when using the FreeBSD ports-build of php, with errors that do not appear to occur when using the php-4.3.10.tar.bz vanilla tarball. While browsing FreeBSD's patches for php-4.3.10, I noticed the following file: http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/php4/files/patch-ext%3a%3astandard%3a%3avar_unserializer.c http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/lang/php4/files/patch-ext%3a%3astandard%3a%3avar_unserializer.c?rev=1.1content-type=text/plain which appears to be based on, among other patches, the following commit: http://cvs.php.net/diff.php/php-src/ext/standard/var_unserializer.c?r1=1.48r2=1.49ty=u Notice that old_data is changed from a zval* to a zval**. Looking at the full picture in the latest version of this file at: http://cvs.php.net/co.php/php-src/ext/standard/var_unserializer.c?r=1.18.4.18 I can see that (void**)old_data is passed to zend_hash_index_find. My C knowledge is rusty at best, but doesn't this result in an zval*** being cast into a void**, i.e. wrong number of indirections? I'd appreciate it if someone more familiar with the PHP sourcecode could have a look at this and determine if there is a bug here. Reproduce code: --- N/A Expected result: N/A Actual result: -- N/A -- Edit this bug report at http://bugs.php.net/?id=31704edit=1
#31332 [Opn-Csd]: unserialize() works terribly slow on huge strings compared to 4.3.9
ID: 31332 Updated by: [EMAIL PROTECTED] Reported By: marekm at apnet dot pl -Status: Open +Status: Closed Bug Type: Performance problem Operating System: * PHP Version: 4CVS, 5CVS (2005-01-04) New Comment: This bug has been fixed in CVS. 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. Previous Comments: [2005-01-15 23:38:55] marekm at apnet dot pl I've tested the Win32 snapshot on my serialized data I attached to the bug report and it seems that it works as fast as it used to work in 4.3.9. Thanks for solving this problem! [2005-01-15 23:27:31] gik at zap dot cl I've compiled the latest snapshot of PHP_4_3 and it seems to be behaving much better on real-life applications (I haven't tried the test program attached to this thread yet). I'll keep testing for a few more days to be sure the server's performance has returned to normal levels. Thanks for the prompt reaction. [2005-01-15 19:55:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Please try this with the next snapshot that is build at 19:30 GMT. I made some changes to unserialize() that should have restored its speed. [2005-01-14 22:47:03] chris at fast4gl dot com I'd agree, this is a huge performance issue in 4.3.10/5.0.3 which really needs to be fixed ASAP. I've seen many servers with performance issues because of this bug since upgrading PHP. [2005-01-14 18:17:55] dondop at gmail dot com It has been quite some time now and this is really an important bug to fix. I understand that open source means that development is done when someone feels like it, but as this is crumbling big shared hosting solutions where sites run on this PHP which use unserialize() I really a fix is developed soon. Comon devs, wake up and smell some coffee :) 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/31332 -- Edit this bug report at http://bugs.php.net/?id=31332edit=1
#31332 [Ver-Fbk]: unserialize() works terribly slow on huge strings compared to 4.3.9
ID: 31332 Updated by: [EMAIL PROTECTED] Reported By: marekm at apnet dot pl -Status: Verified +Status: Feedback Bug Type: Performance problem Operating System: * PHP Version: 4CVS, 5CVS (2005-01-04) New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Please try this with the next snapshot that is build at 19:30 GMT. I made some changes to unserialize() that should have restored its speed. Previous Comments: [2005-01-14 22:47:03] chris at fast4gl dot com I'd agree, this is a huge performance issue in 4.3.10/5.0.3 which really needs to be fixed ASAP. I've seen many servers with performance issues because of this bug since upgrading PHP. [2005-01-14 18:17:55] dondop at gmail dot com It has been quite some time now and this is really an important bug to fix. I understand that open source means that development is done when someone feels like it, but as this is crumbling big shared hosting solutions where sites run on this PHP which use unserialize() I really a fix is developed soon. Comon devs, wake up and smell some coffee :) [2005-01-14 14:40:52] john at jelsoft dot com I would agree with what Gik just said. To quote from the PHP manual: serialize -- Generates a storable representation of a value Or later: serialize() returns a string containing a byte-stream representation of value that can be stored anywhere. This is useful for storing or passing PHP values around without losing their type and structure. I tried some comparisons a while back on different ways to store PHP array data in a DB. I tried storing it in a form where I could run eval($data) and it turned out to be a lot slower than unserialize($data). (Perhaps this would be different given this bug). serialize() seems to be ideal for this situation where large array or object data is to be stored in a DB or shm. So I was surprised that the usages outlined above are 'abuses', as they seem to be using serialize() for exactly what it was intended for. Perhaps the manual needs clarifying if this isn't the case? [2005-01-14 13:52:06] gik at zap dot cl As far as I know, objects stored in shared memory using shm_put_var() are stored serialized. I haven't looked at the sources yet, but the problem affecting unserialize() should also degrade the performance of shm_put_var() which is vastly used to store arrays or other objects in shared memory for _quick_ access. I don't know if there are other functions which use this method internally. I wouldn't call it an abuse to serialize and store an array with 1000 elements in shm, as this is a very efficient way to do data caching. The performance degradation is large enough to make a web server collapse, because of the extra time required to process each request. [2005-01-14 09:05:51] [EMAIL PROTECTED] Sorry to say... but abusing serialize for this is not a good idea in the first place. It's not meant for storing data in this way in the first place. But of course the slowdown shouldn't have been this much. 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/31332 -- Edit this bug report at http://bugs.php.net/?id=31332edit=1
#29241 [Opn-Csd]: PHP memory_limit remote vulnerability(includes 5.0.0)
ID: 29241 Updated by: [EMAIL PROTECTED] Reported By: zor at mysword dot org -Status: Open +Status: Closed Bug Type: Unknown/Other Function Operating System: Linux Mandrake 10.0 PHP Version: 5.0.0 New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: [2004-07-18 10:14:17] zor at mysword dot org Description: Found this site and I thought php people should know about it: http://security.e-matters.de/advisories/112004.html Have a nice day gentlemans. Reproduce code: --- nocode Expected result: noresult Actual result: -- noresult -- Edit this bug report at http://bugs.php.net/?id=29241edit=1
#29132 [Opn-Fbk]: $_SERVER[PHP_AUTH_USER] is not in headers anymore?
ID: 29132
Updated by: [EMAIL PROTECTED]
Reported By: endrju at itrisinajumi dot lv
-Status: Open
+Status: Feedback
Bug Type: *General Issues
Operating System: FreeBSD 5.2.1
PHP Version: 5.0.0
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
This Bug should be fixed in CVS now...
Please test next snapshot.
Previous Comments:
[2004-07-14 06:49:40] endrju at itrisinajumi dot lv
Changed category - General Issues;
[2004-07-14 06:40:59] endrju at itrisinajumi dot lv
Description:
When making HTTP authentication there is no $_SERVER[PHP_AUTH_USER]
in headers (but there is $_SERVER[PHP_AUTH_PW]).
I noticed this when i upgraded to PHP 5.0.0 and checked phpMyAdmin - it
hanged. After some investigation I found that there's no
$_SERVER[PHP_AUTH_USER] in headers.
'./configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-openssl'
'--with-imap=../imap-2004/' '--with-mysql=/usr/local/mysql'
'--with-mssql' '--with-pgsql' '--with-gd' '--with-png' '--with-zlib'
'--with-jpeg' '--with-iconv' '--with-gettext' '--with-xml'
'--with-mcrypt' '--enable-mbstring' '--enable-sockets' '--with-bz2'
'--enable-calendar' '--enable-bcmath'
Reproduce code:
---
?php
if (!isset($_SERVER['PHP_AUTH_USER'])) {
header('WWW-Authenticate: Basic realm=My Realm');
header('HTTP/1.0 401 Unauthorized');
echo 'Text to send if user hits Cancel button';
exit;
} else {
echo pHello {$_SERVER['PHP_AUTH_USER']}./p;
echo pYou entered {$_SERVER['PHP_AUTH_PW']} as your
password./p;
}
?
Expected result:
(This is from http://lv.php.net/manual/en/features.http-auth.php).
I Expected that when i enter username, password and press OK, the code
will output my entered username and password.
Actual result:
--
Script keeps asking the username and password indefinitely;
--
Edit this bug report at http://bugs.php.net/?id=29132edit=1
#28784 [Opn-Fbk]: php.ini: disable_functions does not work at all
ID: 28784
Updated by: [EMAIL PROTECTED]
Reported By: dietrich dot ayala at foundstone dot com
-Status: Open
+Status: Feedback
Bug Type: *Configuration Issues
Operating System: windows xp
PHP Version: 4.3.7
New Comment:
Please double check the position of php.ini or if you made any typo in
it.
disable_functions works fine here on linux and windows.
Previous Comments:
[2004-06-14 23:18:57] dietrich dot ayala at foundstone dot com
Description:
os: winxp
webserver: iis/fastcgi
i set the disable_functions option in php.ini to a value of:
call_user_func_array
then i restart iis, make sure no php.exe instances are running.
then i try my repro code below, and it works fine. it should not let me
use this function.
Reproduce code:
---
?php
function test($arg)
{
echo $arg;
}
$arr = array('hello world');
call_user_func_array('test', $arr);
?
Expected result:
should not let the user use the call_user_func_array function
Actual result:
--
prints hello world
--
Edit this bug report at http://bugs.php.net/?id=28784edit=1
#28784 [Opn-Csd]: php.ini: disable_functions does not work at all
ID: 28784
Updated by: [EMAIL PROTECTED]
Reported By: dietrich dot ayala at foundstone dot com
-Status: Open
+Status: Closed
Bug Type: *Configuration Issues
Operating System: windows xp
PHP Version: 4.3.7
Previous Comments:
[2004-06-14 23:57:32] dietrich dot ayala at foundstone dot com
user error. i have several versions of php on this box, and updated the
wrong php.ini.
sorry for the inconvenience, please close.
[2004-06-14 23:48:12] [EMAIL PROTECTED]
Please double check the position of php.ini or if you made any typo in
it.
disable_functions works fine here on linux and windows.
[2004-06-14 23:18:57] dietrich dot ayala at foundstone dot com
Description:
os: winxp
webserver: iis/fastcgi
i set the disable_functions option in php.ini to a value of:
call_user_func_array
then i restart iis, make sure no php.exe instances are running.
then i try my repro code below, and it works fine. it should not let me
use this function.
Reproduce code:
---
?php
function test($arg)
{
echo $arg;
}
$arr = array('hello world');
call_user_func_array('test', $arr);
?
Expected result:
should not let the user use the call_user_func_array function
Actual result:
--
prints hello world
--
Edit this bug report at http://bugs.php.net/?id=28784edit=1
#22657 [Opn-Bgs]: Weak parsing in rfc1867.c
ID: 22657
Updated by: [EMAIL PROTECTED]
Reported By: vesely at tana dot it
-Status: Open
+Status: Bogus
Bug Type: HTTP related
Operating System: Any
PHP Version: 4.3.0
New Comment:
buf_begin can be NULL, no DOS possible - BOGUS1
searching for ',' is correct this works around a bug
in some IE version - BOGUS2
Previous Comments:
[2003-03-12 03:44:37] vesely at tana dot it
Hi,
watch out rfc1867.c around line 342, in function
next_line() there is (was?) the following code:
if (ptr) {
/* ... */
} else {
/* ... */
line[self-bufsize] = 0;
self-buf_begin = ptr;/* === */
self-bytes_in_buffer = 0;
}
ptr is obviously NULL, buf_begin should never be NULL
or the program may crash. So this is a potential
vulnerability for DOS attackers who submit long lines.
Since you're there, would you mind to check why at line
721, in the rfc1867_post_handler function, there is
boundary_end = strchr(boundary, ',');
Shouldn't it be ';' (semicolon) rather than ',' (comma)?
(Just wandering)
--
Edit this bug report at http://bugs.php.net/?id=22657edit=1
#8187 [Opn-Csd]: Partial FTP Downloads
ID: 8187 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: All PHP Version: 4.0.3pl1 New Comment: This feature is already in PHP 4.3.0 Previous Comments: [2003-02-15 09:02:24] [EMAIL PROTECTED] I'd like to second this, but for an entirely different reason. It would be nice if the ftp_[fput/fget] functions took a 5th, length parameter, so developers could use it similarly to fread/fwrite. This would facilitate the ability to output the progress of the upload/download, because currently, there appears to be no way to let users know that script is actually downloading something. Developers can mearly output something like 'File downloading, please wait...' and hope the user is patient when downloading larger files. [2000-12-09 22:52:00] [EMAIL PROTECTED] Just a short simple feature request: I'd really love the ability to be able to do partial FTP downloads. At the moment the ftp_get() functions download the entire file. It'd be nice to have an optional parameter with how many bytes to download. The reason I ask is that it would be infinitely useful for my FTP search engine. Being able to partial download (say 1000 bytes) lets me know whether a particular FTP site has a ratio or some sort of download restrictions. Thanks in advance. -Adam -- Edit this bug report at http://bugs.php.net/?id=8187edit=1
#19113 [Opn]: HTTP status 200 returned on HTTP CONNECT when mod_proxy not in use
ID: 19113 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: any PHP Version: 4.3.0 New Comment: Well can you tell me why it is severe? Okay it is maybe not correct that it reacts on any string but basicly why should it not react on TINTE / HTTP/1.0 This could be a valid request if the server has loaded mod_tinte v1.0 or whatever. If you dislike the feature you can always check for a valid (from your point of view) request method from within your scripts. Previous Comments: [2003-01-18 20:33:41] [EMAIL PROTECTED] This problem seems more severe than reported here, at least in 4.1.3 with Apache 1.3.26 shipped with Debian GNU/Linux 3.0.1: If mod_php4 is enabled, any (!) string (try foobar\n\n instead of GET / HTTP/1.0\n\n) will return the home page from $DOCUMENT_ROOT/index.php. If we comment out the LoadModule directive for mod_php4, the server returns correctly 501 method not implemented. Interestingly we couldn't reproduce it on an Apache 1.3.26 with PHP 4.2.2, but this may be because of the tested virtual host is not the first one in the httpd.conf. We noticed this while trying to figure out why the Apache answered to requests like \xe3P (probably trying to exploit some bugs in some webserver) with 200 OK instead of 501 method not implemented. An example: With mod_php4: telnet our_host 80 Trying ###.###.###.###... Connected to our_host. Escape character is '^]'. \xe3P !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN HTML HEAD TITLEour_host home page/TITLE /HEAD [...] Without mod_php4: telnet our_host 80 Trying ###.###.###.###... Connected to our_host. Escape character is '^]'. \xe3P !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN HTMLHEAD TITLE501 Method Not Implemented/TITLE /HEADBODY H1Method Not Implemented/H1 \xe3P to /index.php not supported.P Invalid method in request \\xe3PP HR ADDRESSApache/1.3.26 Server at our_host Port 80/ADDRESS /BODY/HTML Connection closed by foreign host. Maybe also interessting: A very long string (e.g. 80.000 characters) correctly leads to an error 414 Request-URI Too Large, equal if mod_php4 is loaded or not. This looks like mod_php4 handles any possible request method, which is passed to it. Is this really the wanted behaviour? Why should PHP change Apache's behaviour in such cases? [2003-01-05 07:41:37] [EMAIL PROTECTED] Verified in Apache 1.3.27/Linux/PHP 4.3.0 [2003-01-04 16:48:32] [EMAIL PROTECTED] Yes; [EMAIL PROTECTED] is correct. My previous comment (bug possibly fixed) was in haste. The problem still exists in 4.3.0. Please, someone in the PHP crew investigate this fully, as it's becoming more and more of an issue and seems to be affecting essentially everyone who uses PHP and Apache. [2003-01-03 23:39:16] [EMAIL PROTECTED] Problem still exists in PHP 4.3.0, i'm running Apache 1.3.27 on FreeBSD. [2003-01-02 06:32:47] [EMAIL PROTECTED] I apologise for not being able to test 4.3.0 or any of the snap releases prior to now -- we use FreeBSD, and we rely on the FreeBSD port of mod_php4. The port author has not upgraded to 4.3.0 yet, and therefore we were stuck using 4.2.3 until earlier this evening when I removed the port and went with the old method of installing off source manually. It seems that this problem may in fact be fixed in 4.3.0. The problem documented no longer appears. 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/19113 -- Edit this bug report at http://bugs.php.net/?id=19113edit=1
#21512 [Opn-Bgs]: mkdir() does not work in safe mode
ID: 21512
Updated by: [EMAIL PROTECTED]
-Reported By: [EMAIL PROTECTED]
+Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Performance problem
Operating System: Rehat 8.0
PHP Version: 4.2.3
New Comment:
It works in 4.3 so obviously it was fixed.
Previous Comments:
[2003-01-08 02:44:12] [EMAIL PROTECTED]
(changed my email address)
[2003-01-08 02:32:51] [EMAIL PROTECTED]
compiled into php:
./configure --with-apxs=/usr/local/apache/bin/apxs
--with-pgsql=/usr/local/pgsql/ --with-mcrypt=/usr/local --with-xml
--with-pdflib --disable-debug
using the following directives in my httpd.conf:
php_admin_value safe_mode 1
php_admin_value safe_mode_exec_dir /usr/local/src/demo/
this expression never evaluates to true:
if(!mkdir($new_dir, 0755)) {
$error = The directory could not be created.;
}
the var $new_dir is always a subdirectory of a directory with umask=000
and mod=777 and ownership=nobody.nobody. The class running the code is
owned by nobody.nobody. Nobody owns the apache server (v.1.3.27)
processes.
If safe_mode is set to false, the mkdir() function works just fine.
Mkdir() + safe mode works just fine under php 4.3 also running under
redhat 8.0, with the same compile options, the same httpd.conf
directives, the same apache version, and the same directory
permissions...aaack!
--
Edit this bug report at http://bugs.php.net/?id=21512edit=1
#21450 [Opn-Csd]: File Posts from Microsoft Web Publishing Wizard don't work.
ID: 21450 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: Windows 2000 Pro PHP Version: 4CVS-2003-01-05 (dev) Assigned To: sesser New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-01-06 02:15:56] [EMAIL PROTECTED] Content-disposition: form-data; filename=etc\root.hint This line of the rfc1867 fileupload lacks a name=whatever attribute. PHP cannot handle anonymous fileuploads for now... (I will implement that) [2003-01-05 22:29:03] [EMAIL PROTECTED] Here is a capture of a complete request made by WPW: POST /temp/fb.php HTTP/1.1 Accept: */* Content-Type: Multipart/Form-Data,boundary=19359@23195#13275 User-Agent: Microsoft HTTP Post (RFC1867) Host: 10.0.0.7 Connection: Keep-Alive Cache-Control: no-cache Content-Length: 3002 --19359@23195#13275 Content-disposition: form-data; filename=etc\root.hint Content-type: application/octet-stream ; This file holds the information on root name servers needed to ; initialize cache of Internet domain name servers ; (e.g. reference this file in the cache . file ; configuration file of BIND domain name servers). ; ; This file is made available by InterNIC registration services ; under anonymous FTP as ; file/domain/named.root ; on server FTP.RS.INTERNIC.NET ; -OR- under Gopher atRS.INTERNIC.NET ; under menu InterNIC Registration Services (NSI) ; submenu InterNIC Registration Archives ; filenamed.root ; ; last update:Aug 22, 1997 ; related version of root zone: 1997082200 ; ; ; formerly NS.INTERNIC.NET ; .360 IN NSA.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 360 A 198.41.0.4 ; ; formerly NS1.ISI.EDU ; .360 NSB.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 360 A 128.9.0.107 ; ; formerly C.PSI.NET ; .360 NSC.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 360 A 192.33.4.12 ; ; formerly TERP.UMD.EDU ; .360 NSD.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 360 A 128.8.10.90 ; ; formerly NS.NASA.GOV ; .360 NSE.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 360 A 192.203.230.10 ; ; formerly NS.ISC.ORG ; .360 NSF.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 360 A 192.5.5.241 ; ; formerly NS.NIC.DDN.MIL ; .360 NSG.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 360 A 192.112.36.4 ; ; formerly AOS.ARL.ARMY.MIL ; .360 NSH.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 360 A 128.63.2.53 ; ; formerly NIC.NORDU.NET ; .360 NSI.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 360 A 192.36.148.17 ; ; temporarily housed at NSI (InterNIC) ; .360 NSJ.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. 360 A 198.41.0.10 ; ; housed in LINX, operated by RIPE NCC ; .360 NSK.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 360 A 193.0.14.129 ; ; temporarily housed at ISI (IANA) ; .360 NSL.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. 360 A 198.32.64.12 ; ; housed in Japan, operated by WIDE ; .360 NSM.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 360 A 202.12.27.33 ; End of File --19359@23195#13275-- [2003-01-05 21:47:40] [EMAIL PROTECTED] When using microsoft web publishing wizard to post files to a php script $_FILES is always empty. Logged in my php error log is: [06-Jan-2003 16:46:49] PHP Warning: File Upload Mime headers garbled in Unknown on line 0 It is able to reteive some of the post values but not the files. Is this really a Microsoft RFC
#21450 [Opn]: File Posts from Microsoft Web Publishing Wizard don't work.
ID: 21450
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
-Bug Type: Unknown/Other Function
+Bug Type: Feature/Change Request
Operating System: Windows 2000 Pro
PHP Version: 4CVS-2003-01-05 (dev)
-Assigned To:
+Assigned To: sesser
New Comment:
Content-disposition: form-data; filename=etc\root.hint
This line of the rfc1867 fileupload lacks a name=whatever
attribute. PHP cannot handle anonymous fileuploads for now... (I will
implement that)
Previous Comments:
[2003-01-05 22:29:03] [EMAIL PROTECTED]
Here is a capture of a complete request made by WPW:
POST /temp/fb.php HTTP/1.1
Accept: */*
Content-Type: Multipart/Form-Data,boundary=19359@23195#13275
User-Agent: Microsoft HTTP Post (RFC1867)
Host: 10.0.0.7
Connection: Keep-Alive
Cache-Control: no-cache
Content-Length: 3002
--19359@23195#13275
Content-disposition: form-data; filename=etc\root.hint
Content-type: application/octet-stream
; This file holds the information on root name servers needed to
; initialize cache of Internet domain name servers
; (e.g. reference this file in the cache . file
; configuration file of BIND domain name servers).
;
; This file is made available by InterNIC registration services
; under anonymous FTP as
; file/domain/named.root
; on server FTP.RS.INTERNIC.NET
; -OR- under Gopher atRS.INTERNIC.NET
; under menu InterNIC Registration Services (NSI)
; submenu InterNIC Registration Archives
; filenamed.root
;
; last update:Aug 22, 1997
; related version of root zone: 1997082200
;
;
; formerly NS.INTERNIC.NET
;
.360 IN NSA.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 360 A 198.41.0.4
;
; formerly NS1.ISI.EDU
;
.360 NSB.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 360 A 128.9.0.107
;
; formerly C.PSI.NET
;
.360 NSC.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 360 A 192.33.4.12
;
; formerly TERP.UMD.EDU
;
.360 NSD.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 360 A 128.8.10.90
;
; formerly NS.NASA.GOV
;
.360 NSE.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 360 A 192.203.230.10
;
; formerly NS.ISC.ORG
;
.360 NSF.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 360 A 192.5.5.241
;
; formerly NS.NIC.DDN.MIL
;
.360 NSG.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 360 A 192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
;
.360 NSH.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 360 A 128.63.2.53
;
; formerly NIC.NORDU.NET
;
.360 NSI.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 360 A 192.36.148.17
;
; temporarily housed at NSI (InterNIC)
;
.360 NSJ.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 360 A 198.41.0.10
;
; housed in LINX, operated by RIPE NCC
;
.360 NSK.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 360 A 193.0.14.129
;
; temporarily housed at ISI (IANA)
;
.360 NSL.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 360 A 198.32.64.12
;
; housed in Japan, operated by WIDE
;
.360 NSM.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 360 A 202.12.27.33
; End of File
--19359@23195#13275--
[2003-01-05 21:47:40] [EMAIL PROTECTED]
When using microsoft web publishing wizard to post files to a php
script $_FILES is always empty. Logged in my php error log is:
[06-Jan-2003 16:46:49] PHP Warning: File Upload Mime headers garbled
in Unknown on line 0
It is able to reteive some of the post values but not the files. Is
this really a Microsoft RFC compliance problem or a PHP problem?
Using the following script:
?php
$fp = fopen('c:\fb.log', 'ab+');
fwrite($fp, \nNew Hit\n**\n);
fwrite($fp, '$_SERVER:' . \n);
fwrite($fp, var_export($_SERVER, true). \n);
fwrite($fp, '$_REQUEST:' . \n);
fwrite($fp, var_export($_REQUEST, true). \n);
fwrite($fp, '$_FILES:' . \n);
fwrite($fp, var_export($_FILES, true). \n);
fwrite($fp, '$_GET:' . \n);
fwrite($fp, var_export($_GET, true). \n);
fwrite($fp, '$_POST:' . \n);
fwrite($fp, var_export($_POST, true) . \n);
$content = var_export(time(), true);
header
#21417 [Csd-Bgs]: PHP is garbage
ID: 21417 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Bogus Bug Type: Unknown/Other Function Operating System: win2000 advanceddatacluster PHP Version: 4.3.0 New Comment: Never feed trolls that hide behind anonymous email accounts. Previous Comments: [2003-01-04 16:05:41] [EMAIL PROTECTED] Hello, Thank you for being as much polite. You've probably not tried our support to get help or you wouldn't act like that. PHP is one of the most efficient language and it works very fine with every of my applications. PHP supports XML, Forms and HTTPs very well and you can believe me when I say that you're not wasting your time. PHP is easy to use and it got a nice documentation plus a nice support, take a look at http://www.php.net/support.php. Thank you for your report. [2003-01-04 15:59:53] [EMAIL PROTECTED] why does php never work? I can get basic scrpts working but anything of any real pupose never works, I feel like I am wasting my time, your inablity to make a working version is frustrating, this scripting language is a joke, after wasting thousands of dollars trying to get this script engine working, I have to drop all attemps to even try, I will go back to developing my asp and xml scripts that actually work back to the foreground of my secure web pages and forms. p.s. thanks for wasting my time assholes -- Edit this bug report at http://bugs.php.net/?id=21417edit=1
#21188 [Opn-Bgs]: VIRUS WARNING!!!!!!
ID: 21188 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows XP PHP Version: 4.2.3 Previous Comments: [2002-12-26 03:59:28] [EMAIL PROTECTED] Hi... I downloaded php version php-4.2.3-Win32 and my computer i now infected by W32.NIMDA.EMC Virus... I got 15 different messages that files in php were infected: Here below you can se two different messages: The file C:\Inetpub\php\dlls\pict0035.eml is infected with the W32.Nimda.enc virus. Unable to repair this file. The file C:\Inetpub\php\browscap\index2.eml is infected with the W32.Nimda.enc virus. Unable to repair this file. There is more infected files.. You should shot down site for downloading because more people can get the virus.. I just want to warn you.. Mensur / www.pixel-design.nu -- Edit this bug report at http://bugs.php.net/?id=21188edit=1
#21188 [Bgs]: VIRUS WARNING!!!!!!
ID: 21188 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows XP PHP Version: 4.2.3 New Comment: From where did you download it? Previous Comments: [2002-12-26 03:59:28] [EMAIL PROTECTED] Hi... I downloaded php version php-4.2.3-Win32 and my computer i now infected by W32.NIMDA.EMC Virus... I got 15 different messages that files in php were infected: Here below you can se two different messages: The file C:\Inetpub\php\dlls\pict0035.eml is infected with the W32.Nimda.enc virus. Unable to repair this file. The file C:\Inetpub\php\browscap\index2.eml is infected with the W32.Nimda.enc virus. Unable to repair this file. There is more infected files.. You should shot down site for downloading because more people can get the virus.. I just want to warn you.. Mensur / www.pixel-design.nu -- Edit this bug report at http://bugs.php.net/?id=21188edit=1
#21191 [Bgs]: Here Documents and EOF
ID: 21191 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *General Issues Operating System: Windows XP Pro/SP1 PHP Version: 4.2.3 New Comment: We do not fix perl bugs. Previous Comments: [2002-12-26 06:04:11] [EMAIL PROTECTED] rofl! [2002-12-26 06:00:56] [EMAIL PROTECTED] #! c:/perl/bin/perl.exe -w # # use strict; #print Content-Type:text/plain\n\n; print END; A B C DE F END^Z If you have the above simple script file you won't get it run! Instead, you will get error: Can't find string terminator END anywhere before EOF at C:\Perl\eg\test.pl line 9. Why? Note that the file ends immediately after the last word 'END'. There is NO new line after it! But, if you add a new line after 'END', the script runs well. That is: #! c:/perl/bin/perl.exe -w # # use strict; #print Content-Type:text/plain\n\n; print END; A B C DE F END ^Z -- Edit this bug report at http://bugs.php.net/?id=21191edit=1
#21114 [Opn-Fbk]: Getting BLOB (image) Field with Sybase db
ID: 21114 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Sybase (dblib) related Operating System: linux 2.4.19 PHP Version: 4.2.3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-12-20 08:39:45] [EMAIL PROTECTED] When selecting an image field from a table sybase_query causes a segmentation fault in apache server. The error occures when converting datatype image to char in file php_sybase_db.c function php_sybase_get_column_content. The problem is that the buffer is to small for the hex-string. The buffer had to be the double size because a char is translated in 2 bytes. If you increase the buffersize to 2*res_length its ok. -- Edit this bug report at http://bugs.php.net/?id=21114edit=1
#20467 [Opn-Csd]: Buffer overflow returning binary
ID: 20467 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Sybase (dblib) related Operating System: Linux PHP Version: 4.2.3 New Comment: No. The typo was already fixed. Previous Comments: [2002-12-11 05:03:21] [EMAIL PROTECTED] Perhaps is better to reopen [2002-12-10 14:04:46] [EMAIL PROTECTED] dbconvert is called passing res_length as source length. This can cause problems... Row dbconvert(NULL,coltype(offset),dbdata(sybase_ptr-link,offset), res_length,SYBCHAR,res_buf,res_length); should be replaced with dbconvert(NULL,coltype(offset),dbdata(sybase_ptr-link,offset), src_length,SYBCHAR,res_buf,res_length); freddy77 [2002-12-10 09:44:50] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2002-12-09 04:11:36] [EMAIL PROTECTED] You have also to decide what result you want for binary data. If you use dbconvert for this type your results will be a hexadecimal string. If you want binary data instead you should manually copy data (use just memcpy) or do a conversion to binary, not to characters. freddy77 [2002-12-07 01:29:42] [EMAIL PROTECTED] Someone familiar with the workings of the sybase extension should definately review the patch and make the necessary corrections before the next RC is out. 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/20467 -- Edit this bug report at http://bugs.php.net/?id=20467edit=1
#20927 [Opn-Bgs]: Crash inside libpq (PQexec) with PHP 4.1.2
ID: 20927 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: PostgreSQL related Operating System: Red Hat Linux 8.0 on Intel PHP Version: 4.3.0RC2 New Comment: It crashs with PHP 4.2.2 because it runs in Apache 2. The PSQL lib ist most probably not thread safe. Previous Comments: [2002-12-11 09:55:43] [EMAIL PROTECTED] I disagree. The bug *IS* in PHP, not libpq. The reason I assert this is as follows: - I tried Apache 1.3.27, 2.0.40 and 2.0.43 with libraries from PostgreSQL 7.2.2, 7.2.3 and 7.3, and PHP 4.2.2, 4.2.3 and PHP 4.3.0RC2. ALL combinations crashed reliably. With PHP 4.1.2, I am *unable* to get a crash. Something in PHP is corrupting memory, and later on, malloc() is failing. I use the same libpq library with Perl and Tcl, and have never yet had a segfault. For more info, here's a stack trace for Red Hat 8.0 with Red Hat's version of Apache (2.0.40) and Red Hat's PHP (4.2.2). Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 8192 (LWP 3305)] 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 (gdb) bt #0 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 #1 0x42073155 in malloc () from /lib/i686/libc.so.6 #2 0x4051881b in completed.1 () from /etc/httpd/modules/libphp4.so #3 0x405c5cb1 in completed.1 () from /etc/httpd/modules/libphp4.so #4 0x405c5fe1 in completed.1 () from /etc/httpd/modules/libphp4.so #5 0x405c615e in completed.1 () from /etc/httpd/modules/libphp4.so #6 0x40522efc in completed.1 () from /etc/httpd/modules/libphp4.so #7 0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so #8 0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so #9 0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so #10 0x4052f6b6 in completed.1 () from /etc/httpd/modules/libphp4.so #11 0x4053df7a in completed.1 () from /etc/httpd/modules/libphp4.so #12 0x4053a7bd in completed.1 () from /etc/httpd/modules/libphp4.so #13 0x0807169c in ap_pass_brigade () #14 0x08078e27 in default_handler () #15 0x08065bf5 in ap_run_handler () #16 0x0806620d in ap_invoke_handler () #17 0x080629c6 in ap_process_request () #18 0x0805e0ac in ap_process_http_connection () #19 0x0806f0d5 in ap_run_process_connection () #20 0x08064238 in child_main () #21 0x0806445a in make_child () #22 0x080644b6 in startup_children () #23 0x08064cdf in ap_mpm_run () #24 0x0806ac5f in main () #25 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 [2002-12-11 09:17:15] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. The crash is the fault of PostgreSQL and not that of PHP. [2002-12-11 06:50:18] [EMAIL PROTECTED] Backtrace for Apache 1.3.27 and PHP 4.3.0RC2: Program received signal SIGSEGV, Segmentation fault. 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 (gdb) where #0 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 #1 0x42073155 in malloc () from /lib/i686/libc.so.6 #2 0x402bda44 in pqResultAlloc () from /usr/lib/libpq.so.2 #3 0x402be3d5 in getRowDescriptions () from /usr/lib/libpq.so.2 #4 0x402be2f1 in parseInput () from /usr/lib/libpq.so.2 #5 0x402be970 in PQgetResult () from /usr/lib/libpq.so.2 #6 0x402bea78 in PQexec () from /usr/lib/libpq.so.2 #7 0x40251626 in zif_pg_query (ht=135421720, return_value=0x812593c, this_ptr=0x0, return_value_used=1) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/ext/pgsql/pgsql.c:931 #8 0x40201692 in execute (op_array=0x80f1e54) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1596 #9 0x40201433 in execute (op_array=0x80f3a84) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #10 0x40201433 in execute (op_array=0x80b0d40) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #11 0x40201433 in execute (op_array=0x80a36a0) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #12 0x40201433 in execute (op_array=0x80a8a24) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #13 0x401f4fdd in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend.c:864 #14 0x401d09d4 in php_execute_script (primary_file=0xb530) ---Type return to continue, or q return to quit--- at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/main/main.c:1549 #15 0x4020525e in
#20927 [Opn-Fbk]: Crash inside libpq (PQexec) with PHP 4.1.2
ID: 20927 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: PostgreSQL related Operating System: Red Hat Linux 8.0 on Intel PHP Version: 4.3.0RC2 New Comment: Uhmm I should read better... What versions of libpq do you use with 4.1.2 and 4.2.x? Previous Comments: [2002-12-11 10:34:38] [EMAIL PROTECTED] Then how do you explain the crash in Apache 1.3.27? It is a PHP bug for sure, because changing PHP versions is the only thing which makes it go away. [2002-12-11 10:32:10] [EMAIL PROTECTED] It crashs with PHP 4.2.2 because it runs in Apache 2. The PSQL lib ist most probably not thread safe. [2002-12-11 09:55:43] [EMAIL PROTECTED] I disagree. The bug *IS* in PHP, not libpq. The reason I assert this is as follows: - I tried Apache 1.3.27, 2.0.40 and 2.0.43 with libraries from PostgreSQL 7.2.2, 7.2.3 and 7.3, and PHP 4.2.2, 4.2.3 and PHP 4.3.0RC2. ALL combinations crashed reliably. With PHP 4.1.2, I am *unable* to get a crash. Something in PHP is corrupting memory, and later on, malloc() is failing. I use the same libpq library with Perl and Tcl, and have never yet had a segfault. For more info, here's a stack trace for Red Hat 8.0 with Red Hat's version of Apache (2.0.40) and Red Hat's PHP (4.2.2). Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 8192 (LWP 3305)] 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 (gdb) bt #0 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 #1 0x42073155 in malloc () from /lib/i686/libc.so.6 #2 0x4051881b in completed.1 () from /etc/httpd/modules/libphp4.so #3 0x405c5cb1 in completed.1 () from /etc/httpd/modules/libphp4.so #4 0x405c5fe1 in completed.1 () from /etc/httpd/modules/libphp4.so #5 0x405c615e in completed.1 () from /etc/httpd/modules/libphp4.so #6 0x40522efc in completed.1 () from /etc/httpd/modules/libphp4.so #7 0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so #8 0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so #9 0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so #10 0x4052f6b6 in completed.1 () from /etc/httpd/modules/libphp4.so #11 0x4053df7a in completed.1 () from /etc/httpd/modules/libphp4.so #12 0x4053a7bd in completed.1 () from /etc/httpd/modules/libphp4.so #13 0x0807169c in ap_pass_brigade () #14 0x08078e27 in default_handler () #15 0x08065bf5 in ap_run_handler () #16 0x0806620d in ap_invoke_handler () #17 0x080629c6 in ap_process_request () #18 0x0805e0ac in ap_process_http_connection () #19 0x0806f0d5 in ap_run_process_connection () #20 0x08064238 in child_main () #21 0x0806445a in make_child () #22 0x080644b6 in startup_children () #23 0x08064cdf in ap_mpm_run () #24 0x0806ac5f in main () #25 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 [2002-12-11 09:17:15] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. The crash is the fault of PostgreSQL and not that of PHP. [2002-12-11 06:50:18] [EMAIL PROTECTED] Backtrace for Apache 1.3.27 and PHP 4.3.0RC2: Program received signal SIGSEGV, Segmentation fault. 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 (gdb) where #0 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 #1 0x42073155 in malloc () from /lib/i686/libc.so.6 #2 0x402bda44 in pqResultAlloc () from /usr/lib/libpq.so.2 #3 0x402be3d5 in getRowDescriptions () from /usr/lib/libpq.so.2 #4 0x402be2f1 in parseInput () from /usr/lib/libpq.so.2 #5 0x402be970 in PQgetResult () from /usr/lib/libpq.so.2 #6 0x402bea78 in PQexec () from /usr/lib/libpq.so.2 #7 0x40251626 in zif_pg_query (ht=135421720, return_value=0x812593c, this_ptr=0x0, return_value_used=1) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/ext/pgsql/pgsql.c:931 #8 0x40201692 in execute (op_array=0x80f1e54) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1596 #9 0x40201433 in execute (op_array=0x80f3a84) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #10 0x40201433 in execute (op_array=0x80b0d40) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #11 0x40201433 in execute (op_array=0x80a36a0) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #12
#20467 [Ctl-Csd]: Buffer overflow returning binary
ID: 20467
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Critical
+Status: Closed
Bug Type: Sybase (dblib) related
Operating System: Linux
PHP Version: 4.2.3
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2002-12-09 04:11:36] [EMAIL PROTECTED]
You have also to decide what result you want for binary data.
If you use dbconvert for this type your results will be a hexadecimal
string. If you want binary data instead you should manually copy data
(use just memcpy) or do a conversion to binary, not to characters.
freddy77
[2002-12-07 01:29:42] [EMAIL PROTECTED]
Someone familiar with the workings of the sybase extension should
definately review the patch and make the necessary corrections before
the next RC is out.
[2002-11-18 13:25:50] [EMAIL PROTECTED]
I found also another problem.
If NULL is returned (length == 0) the loop
while (*p == ' ') --p;
can lead to a buffer underflow,
while (p = res_buf *p == ' ') --p;
fix the problem
freddy77
[2002-11-17 13:34:54] [EMAIL PROTECTED]
I forgot. To check the issue try:
#!/home/freddy/install/bin/php -q
?php
$db_handle = sybase_connect(server,user,pass);
sybase_select_db(tempdb, $db_handle);
$db_result = sybase_query(select convert(varbinary,space(120)));
$res = sybase_fetch_row($db_result);
print \nres=$res[0]\n;
print sybase_num_rows($db_result);
$db_result = sybase_query(select convert(numeric(18,2),1234.89));
$res = sybase_fetch_row($db_result);
print \nres=$res[0]\n;
print sybase_num_rows($db_result);
?
freddy77
[2002-11-17 13:31:00] [EMAIL PROTECTED]
dbconvert convert binary - char returning binary representation so
0x6789 (2 bytes) became '6789' (4 single byte characters)
When converting back to PHP (in ext/sybase/php_sybase_db.c) you pass
the same size buffer leading to a buffer overflow.
Following patch fix problem. It also fix another problem (it remove
last characters from conversion) and avoid future possible buffer
overflows due to strange types (like UNIQUEIDs in MSSQL)
diff -r -u10 php-4.2.3/ext/sybase/php_sybase_db.c
php-4.2.3mod/ext/sybase/php_sybase_db.c
--- php-4.2.3/ext/sybase/php_sybase_db.cWed Mar 6 16:59:42 2002
+++ php-4.2.3mod/ext/sybase/php_sybase_db.c Sun Nov 17 20:08:31 2002
@@ -710,49 +710,51 @@
/*case SYBFLT8:*/
case SYBREAL: {
Z_DVAL_P(result) = (double) floatcol(offset);
Z_TYPE_P(result) = IS_DOUBLE;
break;
}
default: {
if (dbwillconvert(coltype(offset),SYBCHAR)) {
char *res_buf;
int res_length = dbdatlen(sybase_ptr-link,offset);
+ int src_length = res_length;
register char *p;
switch (coltype(offset)) {
case SYBBINARY:
case SYBVARBINARY:
+ res_length *= 2;
+ break;
case SYBCHAR:
case SYBVARCHAR:
case SYBTEXT:
case SYBIMAGE:
break;
default:
/* take no chances, no telling how big
the result would really
be */
res_length += 20;
break;
}
res_buf = (char *) emalloc(res_length+1);
memset(res_buf,' ',res_length+1); /* XXX i'm sure
there's a
better way
#20302 [Opn]: Leaked Descriptors
ID: 20302 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Operating System: Linux 2.4.18 PHP Version: 4.2.2 New Comment: It would be nice if you could give an exact description of what descriptors are open for you. Like a directory listing ... ls -la /proc/pidofapache/fd BTW: The opened script fd can be leaked without any security impact. And it is an apache bug that the fds are leaked. PHP does no accept (its the apache child that accepts). And mysql etc... sockets are opened by the mysqlclient libs... these are responsible for setting the close on exec flag, not PHP. Previous Comments: [2002-12-05 07:27:02] [EMAIL PROTECTED] I got the e-mail stating to try the latest tarball. I downloaded it and grep'ed around. I am not sure how to build a rpm of php that is 100% compatible with RedHat 8.0. The e-mail back was terse and didn't say the problem was replicated or fixed. The tarball has no CHANGELOG. Grep'ing did not show FD_CLOEXEC. Since I am not sure about building a rpm and I cannot find what the fix was, how am I to provide feedback? Was the problem replicated? Did your testing show its now fixed? What files were changed? Are there diffs of the affected code? [2002-12-04 18:16:22] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2002-11-23 16:37:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-07 12:20:30] [EMAIL PROTECTED] Upon investigating the php engine as shipped by RedHat 8.0 with the env_audit program, I have found that php is leaking descriptors (above and beyond what apache is leaking). One descriptor is the php webpage being executed, and 2 copies of the socket returned from accept appear to be leaked. The env_audit program is listed at freshmeat.net, it comes with instructions to audit php. The fix is to add a fcntl(fd, FD_CLOEXEC) after accept and after opening the page. -- Edit this bug report at http://bugs.php.net/?id=20302edit=1
#20750 [Opn-Bgs]: Serious security hole when accessing phpinfo() in a .htaccess protected dir.
ID: 20750
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Apache related
Operating System: all
PHP Version: 4.2.3
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
If you do not want that your users can see this information then do not
give them the ability to view phpinfo().
Previous Comments:
[2002-12-01 13:37:15] [EMAIL PROTECTED]
On all Servers we administrate, we always install an 'info.php' file
which only contains the phpinfo() function.
Now I found that PHP returns the transmitted password in clear text to
the browser. The page is stored in the browsers cache or someone could
just have a look on my screen. :-((
I think this is a serious security hole.
The password should not be returned to the browser in any way, best
would be to show some asterisks ('***'), to show that the variable
exists.
Ulrich Kapp
--
Edit this bug report at http://bugs.php.net/?id=20750edit=1
#20673 [Ver]: Inexplicable arithmetical error due to references
ID: 20673 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Verified Bug Type: Scripting Engine problem Operating System: Win 2000 NT/Linux PHP Version: 4.3.0-dev/4.4.0-dev New Comment: never write something like $a = $a + $a++; if you f.e. try such a construct in C you will get different results depending on the compiler and/or optimisation level. Previous Comments: [2002-11-27 07:04:52] [EMAIL PROTECTED] ? $a = 7; $a = $a + $a++; echo $a; //the result is 14; ? When I add a reference to $a, the behavior of $a + $a++ becomes inexplicable different. Note that $a isn't changed anywhere! ? $a = 7; $b = $a; $a = $a + $a++; echo $a; //the result is 15; ? The only difference is $b = $a, but why $a takes care of references to itself? -- Edit this bug report at http://bugs.php.net/?id=20673edit=1
#20577 [Opn-Csd]: security vulnerability
ID: 20577 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: *General Issues Operating System: all PHP Version: 4.2.3 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. No feedback via e-mail. Previous Comments: [2002-11-22 12:56:17] [EMAIL PROTECTED] In accordance with iDEFENSE's security vulnerability disclosure policy (www.idefense.com/disclosure.html), we wanted to bring a security issue to your attention. Please acknowledge receipt of this information so we can work toward a public disclosure date that is convenient to you in building a fix. Attackers are able to disclose arbitrary files by exploiting a vulnerability in the PHP Group's PHP project's handling of file uploads. This vulnerability is a variation of a vulnerability that was discovered in early April of 2000 (CVE-2000-0860) that affects all versions of PHP prior to version 4.0.3. Scripts that utilize the legacy method for handling file uploads follow these steps: When registering a global variable php_mime_split() calls safe_php_register_variable(). This function in turn runs a check with is_protected_variable(), and if it's not dealing with a protected variable will then call php_register_variable(). is_protected_variable() calls zend_hash_exists() on the rfc1867_protected_variables hash. The php_mime_split() function adds protected variables to the hash with a call to zend_hash_add(). If a user tries to register a variable that is protected (such as the uploaded file's path) the request will be denied since the requested variable name exists in the rfc1867_protected_variables hash. The problem stems from the fact that php_register_variable_ex() manipulates the variable name before it is stored. Leading spaces are removed, and spaces and dots are swapped with underscores. Therefore, if the variable 'file_path' is protected, an attacker can submit ' file_path', thereby bypassing the security checks from the Zend hash functions. However, php_register_variable_ex() will transform ' file_path' into 'file_path' and register it as a global variable. An attacker can utilize this vulnerability to modify the value of the temporary path of an uploaded file to point to another arbitrary file. File uploads are generally handled by either copying uploaded temporary files to another (normally web accessible) directory or by storing them within a database. In either case, an attacker can cause disclosure of arbitrary system files. Sources: iDEFENSE Labs, Nov. 06, 2002 Analysis: (iDEFENSE US) Any remote user can exploit this vulnerability against a script running in an affected server provided that the script is using the legacy register_globals approach to uploaded file management as opposed to the new method that stores file info in the $_FILES array. Successful exploitation of the above-described vulnerability can result in: Disclosure of PHP code. Disclosure of database authentication data. Disclosure of sensitive files on the target server. PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML. More information is available at http://www.php.net. Detection: iDEFENSE has verified the existence of this vulnerability in PHP version 4.2.2. It is suspected and reported that all versions between 4.0.3 and 4.2.3 inclusive are vulnerable. To determine if the vulnerability exists in a specific implementation experiment with the following snippet of code: html body form method=POST enctype=multipart/form-data File 1: input type=file name=file1br File 2: input type=file name=file2p !-- we will overwrite the location for file2 -- input type=hidden name= file2 value=/evil/file/location input type=submit /form hr ? echo File1 location: $file1 br\n; echo File2 location: $file2 br\n; ? /body /html The target server is vulnerable if after submitting the form the script prints: File2 location: /evil/file/location Workaround: Modify your upload handling scripts to utilize the $_FILES[] array method instead of the legacy register_globals method. More information is available at http://www.php.net/manual/en/features.file-upload.php. The code base for PHP v4.3.0pre2 appears to fix the
#20257 [NEW]: libpam.so not available
From: [EMAIL PROTECTED] Operating system: SuSE Linux 8.1 PHP version: 4CVS-2002-11-05 PHP Bug Type: IMAP related Bug description: libpam.so not available SuSE Linux 8.1 comes out of the box with an SSL powered IMAP library. When trying to configure --with-imap and --with-imap-ssl (btw... shouldn't --with-imap-ssl be enough???) you get a not really descriptive error. Configure simply breaks. I tracked this error down to the lack of libpam.so when I created a symbolic link to libpam.so.0 everything works fine. So a) any way to handle that problem? b) --with-imap-ssl should imply --with-imap -- Edit bug report at http://bugs.php.net/?id=20257edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20257r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20257r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20257r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20257r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20257r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20257r=support Expected behavior: http://bugs.php.net/fix.php?id=20257r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20257r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20257r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20257r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20257r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20257r=dst IIS Stability: http://bugs.php.net/fix.php?id=20257r=isapi
#19876 [Opn-Fbk]: Problem with parse_url() function...
ID: 19876 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *URL Functions Operating System: Windows 2000 Pro (Sp3) PHP Version: 4CVS-2002-10-11 New Comment: Please wait until the next developer snapshot is generated and try again. Previous Comments: [2002-10-11 23:31:53] [EMAIL PROTECTED] The lack for formatting for phpinfo() when html_errors are Off is intentional. parse_url() was recently rewritten from scratch that probably introduced the bug you are seeing. I'll look into it in more detail. [2002-10-11 23:26:58] [EMAIL PROTECTED] Here's a link to the phpinfo at my machine: http://onionman.homeip.net/phpinfo/ A weird thing i noticed is that if i have 'html_errors = Off' in my php.ini file, then phpinfo looses all it formatting and is unreadable... is it supposed to be like this? Anyway... i doublechecked the parse_url bug by going back to an older snapshot (2002-10-06), and there it works like expected... and then trying latest snap again (2002-10-12), and there it's the same result as before... so either something has introduced a bug there since last week... or my machine is behaving strange... ;) /OnionMan [2002-10-11 23:00:11] [EMAIL PROTECTED] The 1 comes from 'echo print_r' you do not need to echo print_r() it'll do it automatically. The missing letter is something I am unable to replicate on any of my machines. Could you please should output of phpinfo() on your system, maybe that'll yeild some clues. [2002-10-11 22:54:02] [EMAIL PROTECTED] Snapshot used: php4-win32-200210120200.zip This simple script parses an ftp-url: ?php $url = ftp://gandalf:[EMAIL PROTECTED]/foo/bar/index.php?page=news;; $parts = parse_url($url); echo 'pre'.\n; echo print_r($parts).\n; echo '/pre'.\n; ? When i run the script i get this output: Array ( [scheme] = ftp [host] = www.moria.com [user] = gandalf [pass] = mello [path] = /foo/bar/index.php [query] = page=news ) 1 Note the cropped password value... it is cropped by one charachter... last snapshot i tested (2002-10-06) did not have this behaviour. BTW: What does the 1 that is output after the value pairs mean? -- Edit this bug report at http://bugs.php.net/?id=19876edit=1
#19774 [Opn-Bgs]: isset behaviour change 4.2.2 - 4.2.3
ID: 19774 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: Solars 8 Sparc PHP Version: 4.2.3 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php The behaviour in 4.2.3 is the correct one. I would be very suprised if this breaks any scripts because it was not working before, now it works. Previous Comments: [2002-10-05 17:41:45] [EMAIL PROTECTED] It's not really a bug, its a new way to return things with this function. By the way I agree that it's not really a good thing that it changed. [2002-10-05 17:38:59] [EMAIL PROTECTED] ?php des not make difference for me. In our app scripts we use ?php. Anyway, the one I provided is just a test script to demonstrate this bug. We have problem with our application and would like to know, if we should wait for php 4.2.4 or should we start changing and testing this application in order to accomodate this new behaviour. [2002-10-05 17:08:57] [EMAIL PROTECTED] Please Test: ?php echo :.isset($code).:; ? [2002-10-05 16:49:32] [EMAIL PROTECTED] Hi, We are using apache 1.2.26, register_globals is on. configure line: ./configure --with-oci8 --with-mysql=/usr/local/mysql --with-apache=../apache_1.3.26 --enable-track-vars --with-mcrypt --enable-gd-native-ttf --with-gd --with-jpeg-dir --with-png-dir=/usr/local --with-freetype-dir=/usr/local --with-zlib-dir=/usr --with-curl Here is out test script, test php: ?echo :.isset($code).:;? with php 4.2.2 http://something/test.php?code producec output: :: with php 4.2.3 http://something/test.php?code producec output: :1: It seems like isset behaviour changed from 4.2.2 to 4.2.3. This required changes into our application, I'd like to know if this behaviour changes again or will stay like it is with 4.2.3. -- Edit this bug report at http://bugs.php.net/?id=19774edit=1
#18252 [Opn]: angle in ImageTTFText now works clockwise
ID: 18252 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: GD related Operating System: FreeBSD 4.6 PHP Version: 4.3.0-dev New Comment: Reproduced! This is a problem within libfreetype. Depending on the freetype version the angles are counted in different directions. Previous Comments: [2002-09-11 08:57:19] [EMAIL PROTECTED] I am still having this same problem - tried everything. Here is what script produces: http://www.dpetrov.com/misc/ttf/test4.php And here is the source: http://www.dpetrov.com/misc/ttf/test4.phps [2002-09-09 01:00:05] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2002-08-09 00:45:14] [EMAIL PROTECTED] The sample image provided by dams, http://www.deadmime.org/~dank/test.png Is this what you were looking for? Mind you this is GD 2.0.1 built without FreeType support (apparently on OSX the two don't mix nicely). If this is what you were looking for, any chance you can try rebuilding GD without FreeType support, just to narrow down the differences of course. [2002-07-18 13:44:04] [EMAIL PROTECTED] Just note that I could NOT reproduce this with latest CVS. (with Linux) [2002-07-18 13:23:27] [EMAIL PROTECTED] I think the bug should be reopened, since it is reproducable. 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/18252 -- Edit this bug report at http://bugs.php.net/?id=18252edit=1
Bug #16373 Updated: Security Hole
ID: 16373 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *General Issues Operating System: Red Hat 7.1 PHP Version: 4.1.2 New Comment: You are not running php 4.1.2 but php 4.0.1pl2. Your version of php is very old and remotely exploitable. Previous Comments: [2002-04-01 07:56:46] [EMAIL PROTECTED] What date is it today? [2002-04-01 07:52:55] [EMAIL PROTECTED] You can view this URL at http://www.crescentart.com/php/. [2002-04-01 07:45:20] [EMAIL PROTECTED] I am writing to report a possible security hole. The problem is that when I run the phpinfo(); function PHP outputs it's cinfiguration info but there is a picture of a cocasion male with pencils sticking out of his mouth in the upper right hand corner. Please let me know if this is a problem with my system security or if the problemis with the PHP program. Eric -- Edit this bug report at http://bugs.php.net/?id=16373edit=1
Bug #8744 Updated: call to header() causes CGI error
ID: 8744 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Critical +Status: Feedback Bug Type: IIS related Operating System: Windows 2000 PHP Version: 4.1.1 New Comment: Guys try 4.1.2 I think this is just the 1000th duplicate of the header bug. Previous Comments: [2002-03-25 02:57:10] [EMAIL PROTECTED] Hi to all, I have one Point to add. I use two copies of a WebSite on a Server running IIS (Test Real). One of them dosn't have this Problem at all, but the Second one Produces this error. Both use the same Database Server. I compared the IIS Web Configuration, but both are the same! I can not find the error! Kiumars Ansari / Hamburg [2002-03-18 17:15:58] [EMAIL PROTECTED] I read your errors and found: FATAL: erealloc(): Unable to allocate 1043162510 bytes this seems to me like a MSSQL-PHP issue which comes along with the use of MSSQLs NTEXT and NVARCHAR Fields, after connecting to the MSSQL-database you must launch a SQL statement which limits the returning size fo this fields eg. 'SET TEXTSIZE 10'. hope this helps Gustav Graf [2002-03-14 06:52:39] [EMAIL PROTECTED] i noticed various problem working on header() function. in the worst case i get out a segmentation fault on my linux 2.4.4 running apache 1.3.22 + php 4.1.1 i will post a new bug thread about it in few minutes... bye, stain [2002-03-12 15:41:15] [EMAIL PROTECTED] Hi All, I also have this problem and it is definately related to MSSQL because I also used the same code with a MySQL database and the error doesn't exist. Thanks, Steve [2002-02-16 05:20:10] [EMAIL PROTECTED] This problem also occurs when using apache, and a real url as opposed to a relative url (ie, having the php.exe engine exposed in the docroot). I cannot determine if it's the same cause, but it's definitely the same symptom. if this could get fixed, it'd fix a big security hole we have now. james. 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/8744 -- Edit this bug report at http://bugs.php.net/?id=8744edit=1
Bug #10027 Updated: HTTP_REFERER
ID: 10027 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: *Web Server problem Operating System: Linux Redhat 6.2 PHP Version: 4.0.4pl1 New Comment: HTTP_WEFERER has nothing todo with PHP its some data your browser gives out to the world. Previous Comments: [2002-03-07 04:19:22] [EMAIL PROTECTED] Both windows2000 FreeBSD 3.4 found SAME Problem With Apache! How to decode HTTP_WEFERER? [2001-04-29 11:50:00] [EMAIL PROTECTED] No feedback. closing [2001-03-29 11:11:48] [EMAIL PROTECTED] Works for me just fine with latest CVS. (snapshot can be found at http://snaps.php.net/ ) Which webserver are you using? Apache? --Jani [2001-03-27 11:31:50] [EMAIL PROTECTED] Linking to a phpinfo() page should give a valid HTTP_REFERER value, however, I don't see it. The only thing I see remotely close to that is: HTTP_WEFERER WCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARH -- Edit this bug report at http://bugs.php.net/?id=10027edit=1
Bug #15772 Updated: PHP is developed and maintained by morons
ID: 15772 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: *General Issues Operating System: all PHP Version: 4.0.6 New Comment: This would be a violation of (at least german) userdata protection laws. Previous Comments: [2002-03-05 07:12:57] [EMAIL PROTECTED] Would it be possible to post the IP addresses of the users of php.net? Some would very much appreciate that. [2002-03-04 12:22:19] [EMAIL PROTECTED] Folks, please, we need a working fix, stop bitching at each other. Is the official response from the PHP team that the fix is in CVS, so it is fixed? [2002-03-03 02:34:50] [EMAIL PROTECTED] Fuck you ...php This posting is most probably a fake, cause there is noone at [EMAIL PROTECTED] And for the rest of the trolls: The patch from [EMAIL PROTECTED] will not be applied. All his claims were as bogus as his patch. He just added lots of redundant code. And the best: In his patch every single variable is double freed. You know how dangerous that is... [2002-03-02 15:56:21] [EMAIL PROTECTED] Fuck you ...php [2002-03-01 07:03:10] [EMAIL PROTECTED] I have had a long look at rfc1867.c v 1.71.2.2 2002/02/21 from a download of php4.1.2 today (1 Mar 10:00 CET). There are a large number of dubious cases of handling of the buffer being processed. The following diffs address most of these (I believe). I am posting the patches to the php-dev list, since it's difficult if not impossible to create a properfly formatted diff in this edit window. 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/15772 -- Edit this bug report at http://bugs.php.net/?id=15772edit=1
Bug #15772 Updated: PHP is developed and maintained by morons
ID: 15772
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: *General Issues
Operating System: all
PHP Version: 4.0.6
New Comment:
Fuck you ...php
This posting is most probably a fake, cause there is
noone at [EMAIL PROTECTED]
And for the rest of the trolls:
The patch from [EMAIL PROTECTED] will not be applied.
All his claims were as bogus as his patch.
He just added lots of redundant code. And the best:
In his patch every single variable is double freed.
You know how dangerous that is...
Previous Comments:
[2002-03-02 15:56:21] [EMAIL PROTECTED]
Fuck you ...php
[2002-03-01 07:03:10] [EMAIL PROTECTED]
I have had a long look at rfc1867.c v 1.71.2.2 2002/02/21
from a download of php4.1.2 today (1 Mar 10:00 CET). There are a large
number of dubious cases of handling of the buffer being processed. The
following diffs address most of these (I believe). I am posting the
patches to the php-dev list, since it's difficult if not impossible to
create a properfly formatted diff in this edit window.
[2002-02-28 17:50:58] [EMAIL PROTECTED]
How about this patch:
--- main/rfc1867.c.orig Thu Feb 28 14:08:25 2002
+++ main/rfc1867.c Thu Feb 28 14:33:03 2002
@@ -163,20 +163,28 @@
SAFE_RETURN;
}
/* some other headerfield
found, skip it */
- loc = (char *) memchr(ptr,
'\n', rem)+1;
+ loc = (char *) memchr(ptr,
'\n', rem);
if (!loc) {
/* broken */
php_error(E_WARNING,
File Upload Mime headers garbled ptr: [%c%c%c%c%c], *ptr, *(ptr + 1),
*(ptr + 2), *(ptr
+ 3), *(ptr + 4));
SAFE_RETURN;
}
+ else
+ {
+ loc++;
+ }
while (*loc == ' ' || *loc ==
'\t') {
/* other field is
folded, skip it */
- loc = (char *)
memchr(loc, '\n', rem-(loc-ptr))+1;
+ loc = (char *)
memchr(loc, '\n', rem-(loc-ptr));
if (!loc) {
/* broken */
php_error(E_WARNING, File Upload Mime headers garbled ptr:
[%c%c%c%c%c], *ptr, *(ptr + 1), *(ptr +
2), *(ptr + 3), *(ptr + 4));
SAFE_RETURN;
}
+ else
+ {
+ loc++;
+ }
}
rem -= (loc - ptr);
ptr = loc;
@@ -232,6 +240,10 @@
* pre 4.0.6 code here
*/
loc2 = memchr(loc + 1, '\n',
rem);
+ if (!loc2) {
+ php_error(E_WARNING,
File Upload Mime headers - no newline);
+ SAFE_RETURN;
+ }
rem -= (loc2 - ptr) + 1;
ptr = loc2 + 1;
/* is_arr_upload is true when
name of file upload field
[2002-02-28 05:06:42] [EMAIL PROTECTED]
You are again wrong, cnt must be supplied.
I advise you to think before you speak.
A POST fileupload block can have lots of '\0's in it.
Without the number of bytes it would be impossibe to
handle such a block.
[2002-02-28 04:59:29] [EMAIL PROTECTED]
I'll admit that I did not examine the rest of the program to see if the
buffer was '\0'-terminated, however if it is, it's not just me that
thought it wasn't - whoever wrote the routine thought it wasn't either.
Bug #15102 Updated: Upload fails (internal error 500)
ID: 15102 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Red Hat 7.2 PHP Version: 4.0.6 New Comment: Fileupload in 4.0.6 was kinda broken. I am very sure that 4.1.0 and 4.1.1 fix that issue. Otherwise tell us what browser you are using. Previous Comments: [2002-02-18 09:46:37] [EMAIL PROTECTED] I'm unable to install 4.1.1 for now, can't test. [2002-02-04 02:26:57] [EMAIL PROTECTED] Could you check if this problem is in 4.1.1? [2002-01-20 17:49:56] [EMAIL PROTECTED] So my ISP changed to Apache 3.1.19, still running redhat 7.2 and php 4.0.6. Problem still exists. I have compiled and installed 4.0.5 in my directory and script is running fine. Fabrice. [2002-01-19 20:26:07] [EMAIL PROTECTED] Hi, I have compiled 4.0.4pl1 on the system (simple static install, --with-mysql --with-apache, --host i386-redhat-linux, everything else defaulted, and the script works fine, so there is a problem with 4.0.6. I can't install RPMS as I don't have rpm access. I opened a ticket with the ISP for them to check the configuration, but I don't understand why PHP barfs. I will try with 4.0.5 tomorrow. Fabrice. [2002-01-18 14:27:46] [EMAIL PROTECTED] The only log I know about is error_log on /usr/local/apache/log is there anything else I should look at? [Fri Jan 18 14:22:53 2002] [error] [client 151.200.238.39] Premature end of script headers: /home/usr235/html/upload.php phpinfo says: './configure' '--with-mysql=/usr/local/mysql' '--prefix=/usr/local/php' '--with-mck=/usr/local/mck-3.2.0.3-linux' '--with-dbase' '--with-pfpro=/usr/local/pfpro' '--enable-discard-path' '--prefix=/usr/local' '--with-gd' '--enable-gdbm' '--enable-bcmath' '--with-config-file-path=/usr/local/apache' '--enable-magic-quotes' '--enable-ftp' Server API CGI Virtual Directory Support disabled Configuration File (php.ini) Path /usr/local/apache Note that there is no php.ini in this path, or anywhere on the server. Finally someone that agrees with me that this should work!!! 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/15102 -- Edit this bug report at http://bugs.php.net/?id=15102edit=1
