Bug #64745 [Asn]: hash_pbkdf2() truncates data when using default length and hex output
Edit report at https://bugs.php.net/bug.php?id=64745&edit=1 ID: 64745 Updated by: ircmax...@php.net Reported by:ezzatron at gmail dot com Summary:hash_pbkdf2() truncates data when using default length and hex output Status: Assigned Type: Bug Package:hash related PHP Version:5.5.0beta4 Assigned To:ircmaxell Block user comment: N Private report: N New Comment: Ahh, very interesting find. Will confirm, write a test case, and push a fix for it later today. Thanks for the report! Previous Comments: [2013-05-01 00:18:45] ezzatron at gmail dot com Description: When passing 0 as the length to hash_pbkdf2(), the behaviour is inconsistent between raw output and hex-encoded output. See the test script for a concrete example. There are also no tests for the use case where length is defaulted in the current test suite (http://bit.ly/YcgMMu). I'm attempting to write a compatibility library for this function for PHP versions earlier that 5.5, so the test suite for https://github.com/eloquent/pbkdf2-compat and its build history in Travis CI may also be useful, as it documents the current behaviour more extensively. Test script: --- https://bugs.php.net/bug.php?id=64745&edit=1
Bug #64745 [Asn->Csd]: hash_pbkdf2() truncates data when using default length and hex output
Edit report at https://bugs.php.net/bug.php?id=64745&edit=1 ID: 64745 Updated by: ircmax...@php.net Reported by:ezzatron at gmail dot com Summary:hash_pbkdf2() truncates data when using default length and hex output -Status: Assigned +Status: Closed Type: Bug Package:hash related PHP Version:5.5.0beta4 Assigned To:ircmaxell Block user comment: N Private report: N New Comment: Automatic comment on behalf of ircmax...@gmail.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=540a5a52e89fce6da19d6f79dd1eda587a25b396 Log: Fix #64745 hash_pbkdf2 truncation issue Previous Comments: [2013-05-15 13:06:14] ircmax...@php.net Ahh, very interesting find. Will confirm, write a test case, and push a fix for it later today. Thanks for the report! [2013-05-01 00:18:45] ezzatron at gmail dot com Description: When passing 0 as the length to hash_pbkdf2(), the behaviour is inconsistent between raw output and hex-encoded output. See the test script for a concrete example. There are also no tests for the use case where length is defaulted in the current test suite (http://bit.ly/YcgMMu). I'm attempting to write a compatibility library for this function for PHP versions earlier that 5.5, so the test suite for https://github.com/eloquent/pbkdf2-compat and its build history in Travis CI may also be useful, as it documents the current behaviour more extensively. Test script: --- https://bugs.php.net/bug.php?id=64745&edit=1
Bug #65093 [Asn->Nab]: password_hash ignores salts with spaces
Edit report at https://bugs.php.net/bug.php?id=65093&edit=1
ID: 65093
Updated by: ircmax...@php.net
Reported by:michael at squiloople dot com
Summary:password_hash ignores salts with spaces
-Status: Assigned
+Status: Not a bug
Type: Bug
Package:hash related
Operating System: Windows Vista SP2
PHP Version:5.5.0
Assigned To:ircmaxell
Block user comment: N
Private report: N
New Comment:
This is not a bug. This is as designed.
The reason is that crypt requires a salt that's base64 encoded. A space
character is not a valid character in the salt. Therefore, password_hash will
attempt to use the salt directly (if it's valid in the base64 character set).
But any character outside a-zA-Z0-9./ and it'll base64 encode the salt first.
You can test this yourself:
echo password_hash('this is a test', PASSWORD_DEFAULT, array('salt' =>
'thisisatestthisis test'));
echo "\n";
echo password_hash('this is a test', PASSWORD_DEFAULT, array('salt' =>
'thisisatestthisis test'));
Produces the same result twice in a row:
$2y$10$dGhpc2lzYXRlc3R0aGlzaOZPioeRNSLNeG3cuJW56OSusfQ5SjKdO
$2y$10$dGhpc2lzYXRlc3R0aGlzaOZPioeRNSLNeG3cuJW56OSusfQ5SjKdO
Which indicates that it's actually encoding the salt you pass in, rather than
generating a random one.
So it's still using your salt, and it's most definitely not failing.
Closing as Not A Bug. Thanks for the report!
Previous Comments:
[2013-06-22 12:36:11] michael at squiloople dot com
Would it be worth then having an error or a boolean/null return value rather
than
have it "fail" silently? If at any point the allowed characters for the salt
were
to extend then past hashes (where a salt was generated by the developer with
previously invalid characters) would be broken.
If you give the developer the option to provide a value then surely it should
be
either accepted or denied rather than just ignored.
[2013-06-22 05:48:33] r...@php.net
I think it's only a documentation problem which should explains which are the
allowed characters in the salt (from code: a-z A-Z 0-9 . /)
(notice: It is strongly recommended that you do not generate your own salt for
this function)
[2013-06-21 22:37:03] michael at squiloople dot com
Description:
When manually setting a salt which contains spaces the function ignores it and
automatically generates its own.
Test script:
---
echo password_hash('this is a test', PASSWORD_DEFAULT, array('salt' =>
'thisisatestthisisatest'));
echo '';
echo password_hash('this is a test', PASSWORD_DEFAULT, array('salt' =>
'thisisatestthisis test'));
Expected result:
$2y$10$thisisatestthisisateseLNFJ7M2ONUSijVBKli7sVFN6rQm7o36
$2y$10$thisisatestthisis tesOZPioeRNSLNeG3cuJW56OSusfQ5SjKdO
(with the part after the salt being whatever it would be)
Actual result:
--
$2y$10$thisisatestthisisateseLNFJ7M2ONUSijVBKli7sVFN6rQm7o36
$2y$10$dGhpc2lzYXRlc3R0aGlzaOZPioeRNSLNeG3cuJW56OSusfQ5SjKdO
--
Edit this bug report at https://bugs.php.net/bug.php?id=65093&edit=1
Req #60813 [Opn->Csd]: Implement PBKDF2 function in hash
Edit report at https://bugs.php.net/bug.php?id=60813&edit=1 ID: 60813 Updated by: ircmax...@php.net Reported by:ircmax...@php.net Summary:Implement PBKDF2 function in hash -Status: Open +Status: Closed Type: Feature/Change Request Package:hash related Operating System: All PHP Version:trunk-SVN-2012-01-19 (snap) -Assigned To: +Assigned To:ircmaxell Block user comment: N Private report: N New Comment: Implemented in 5.5.0 Previous Comments: [2012-06-12 17:47:25] ircmax...@php.net This has been submitted as a pull request. RFC to follow: https://github.com/php/php-src/pull/105 [2012-01-19 22:00:52] ircmax...@php.net Description: I propose to implment a PBKDF2 derivation function in the hash package as hash_pbkdf2(). PBKDF2 is defined in PKCS#5 (RFC 2898). The method for password hash derivation is currently used by Blackberry, Apple iOS, Microsoft, OpenOffice, and more (not all for password storage, but all for password based hashing). The patch also cleans up hash_hmac a little bit to split out some common functionality into a few inline functions (since PBKDF2 relies heavily on hmac). Test script: --- https://bugs.php.net/bug.php?id=60813&edit=1
Bug #62443 [Opn->Asn]: Crypt SHA256/512 Segfaults With Malformed Salt
Edit report at https://bugs.php.net/bug.php?id=62443&edit=1 ID: 62443 Updated by: ircmax...@php.net Reported by:ircmax...@php.net Summary:Crypt SHA256/512 Segfaults With Malformed Salt -Status: Open +Status: Assigned Type: Bug Package:Reproducible crash Operating System: All PHP Version:master-Git-2012-06-28 (Git) -Assigned To: +Assigned To:ircmaxell Block user comment: N Private report: N Previous Comments: [2012-06-29 00:02:33] ircmax...@php.net Description: Crypt() SHA256 and SHA512 segfault when passed a salt that contains a null byte. This is because the emalloc call and the memset call use different length inputs for the `output` string. The memset call then overflows the buffer. Test script: --- and Expected result: No output Actual result: -- Either segmentation fault (sha512) or zend_mm_heap corrupted (sha256) -- Edit this bug report at https://bugs.php.net/bug.php?id=62443&edit=1
Bug #62443 [Asn->Csd]: Crypt SHA256/512 Segfaults With Malformed Salt
Edit report at https://bugs.php.net/bug.php?id=62443&edit=1 ID: 62443 Updated by: ircmax...@php.net Reported by:ircmax...@php.net Summary:Crypt SHA256/512 Segfaults With Malformed Salt -Status: Assigned +Status: Closed Type: Bug Package:Reproducible crash Operating System: All PHP Version:master-Git-2012-06-28 (Git) Assigned To:ircmaxell Block user comment: N Private report: N New Comment: This has been fixed in the 5.3, 5.4 and master branches. Previous Comments: [2012-06-29 01:03:13] ircmax...@php.net Automatic comment on behalf of ircmax...@ircmaxell.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=7e8276ca68fc622124d51d18e4f7b5cde3536de4 Log: Fixed bug #62443 (Crypt SHA256/512 Segfaults With Malformed Salt) [2012-06-29 00:02:33] ircmax...@php.net Description: Crypt() SHA256 and SHA512 segfault when passed a salt that contains a null byte. This is because the emalloc call and the memset call use different length inputs for the `output` string. The memset call then overflows the buffer. Test script: --- and Expected result: No output Actual result: -- Either segmentation fault (sha512) or zend_mm_heap corrupted (sha256) -- Edit this bug report at https://bugs.php.net/bug.php?id=62443&edit=1
Bug #63363 [Opn->Asn]: Curl silently accepts boolean true for SSL_VERIFYHOST
Edit report at https://bugs.php.net/bug.php?id=63363&edit=1 ID: 63363 Updated by: ircmax...@php.net Reported by:ircmax...@php.net Summary:Curl silently accepts boolean true for SSL_VERIFYHOST -Status: Open +Status: Assigned Type: Bug Package:*Network Functions Operating System: All PHP Version:Irrelevant -Assigned To: +Assigned To:ircmaxell Block user comment: N Private report: N Previous Comments: [2012-10-25 16:41:21] ircmax...@php.net Description: The CURL option SSL_VERIFYHOST accepts a long value to indicate the verification that should be applied. The following values are valid: 0 - No verification 1 - Check a host is present in cert 2 - Check cert's host matches request's host The problem is that a boolean true is cast to a long 1. Therefore, code that does the following: curl_setopt($c, CURLOPT_SSL_VERIFYHOST, true) appears to be verifying the host. However, it's actually not. This can create security issues that are very hard to find by reading code. Test script: --- https://bugs.php.net/bug.php?id=63363&edit=1
Bug #63363 [Asn->Csd]: Curl silently accepts boolean true for SSL_VERIFYHOST
Edit report at https://bugs.php.net/bug.php?id=63363&edit=1 ID: 63363 Updated by: ircmax...@php.net Reported by:ircmax...@php.net Summary:Curl silently accepts boolean true for SSL_VERIFYHOST -Status: Assigned +Status: Closed Type: Bug Package:*Network Functions Operating System: All PHP Version:Irrelevant Assigned To:ircmaxell Block user comment: N Private report: N New Comment: Fixed in master / 5.4 branch Previous Comments: [2012-10-25 18:51:32] ja...@php.net Thx for creating the bug. Here is the pull request against master: https://github.com/php/php-src/pull/221 The change is minimal and the difference between ext/curl/interface.c from master to >5.4 is also minimal. This should be easy to cherry-pick from master. - JJ [2012-10-25 16:41:21] ircmax...@php.net Description: The CURL option SSL_VERIFYHOST accepts a long value to indicate the verification that should be applied. The following values are valid: 0 - No verification 1 - Check a host is present in cert 2 - Check cert's host matches request's host The problem is that a boolean true is cast to a long 1. Therefore, code that does the following: curl_setopt($c, CURLOPT_SSL_VERIFYHOST, true) appears to be verifying the host. However, it's actually not. This can create security issues that are very hard to find by reading code. Test script: --- https://bugs.php.net/bug.php?id=63363&edit=1
[PHP-BUG] Req #60789 [NEW]: pow() uses floats if one argument is a float
From: Operating system: *nix PHP version: trunk-SVN-2012-01-18 (SVN) Package: Math related Bug Type: Feature/Change Request Bug description:pow() uses floats if one argument is a float Description: I ran into an issue with pow() that causes it to lose precision on 64 bit platforms if one or more of the arguments is a float. I've attached a patch that fixes this by checking if both arguments are exactly representable as an integer, and if so converting to an integer. This attempts to retain as much precision as possible by letting the result be an exact representation where possible. Additionally, the patch fixes a tested-for-bug on 64 bit platforms where: pow(-9.2233720368548E+18, 9223372036854775807) == INF when it should be -INF. Test script: --- var_dump((int) (pow(2, (float) 55) - 1)); Expected result: int(36028797018963967) Actual result: -- int(36028797018963968) -- Edit bug report at https://bugs.php.net/bug.php?id=60789&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60789&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60789&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60789&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60789&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60789&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60789&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60789&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60789&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60789&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60789&r=support Expected behavior: https://bugs.php.net/fix.php?id=60789&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60789&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60789&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60789&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60789&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60789&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60789&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60789&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60789&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60789&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60789&r=mysqlcfg
Req->Bug #60789 [Opn]: pow() uses floats if one argument is a float
Edit report at https://bugs.php.net/bug.php?id=60789&edit=1 ID: 60789 User updated by:ircmaxell at gmail dot com Reported by:ircmaxell at gmail dot com Summary:pow() uses floats if one argument is a float Status: Open -Type: Feature/Change Request +Type: Bug Package:Math related Operating System: *nix PHP Version:trunk-SVN-2012-01-18 (SVN) Block user comment: N Private report: N New Comment: Changing type to bug, as this fixes the implementation to correspond to the docs: http://us3.php.net/pow Specifically: "base raised to the power of exp. If the result can be represented as integer it will be returned as type integer, else it will be returned as type float." Previous Comments: [2012-01-18 13:00:30] ircmaxell at gmail dot com Description: I ran into an issue with pow() that causes it to lose precision on 64 bit platforms if one or more of the arguments is a float. I've attached a patch that fixes this by checking if both arguments are exactly representable as an integer, and if so converting to an integer. This attempts to retain as much precision as possible by letting the result be an exact representation where possible. Additionally, the patch fixes a tested-for-bug on 64 bit platforms where: pow(-9.2233720368548E+18, 9223372036854775807) == INF when it should be -INF. Test script: --- var_dump((int) (pow(2, (float) 55) - 1)); Expected result: int(36028797018963967) Actual result: -- int(36028797018963968) -- Edit this bug report at https://bugs.php.net/bug.php?id=60789&edit=1
[PHP-BUG] Bug #52655 [NEW]: SimpleXMLIterator supports ArrayAccess without implementing Interface
From: Operating system: CentOS 5.5 PHP version: 5.3.3 Package: SimpleXML related Bug Type: Bug Bug description:SimpleXMLIterator supports ArrayAccess without implementing Interface Description: This is more of a consistency issue, but I'm submitting it as a bug since it prevents certain type checks in PHP code. SimpleXMLIterator does not implement the ArrayAccess interface (and neither does its parent SimpleXML). And the documentation says nothing about access via array syntax. However the class itself does support that method of access. To resolve the issue, two things can be done. First, documentation should be updated to reflect that method of access. Second, SimpleXMLIterator should implement the ArrayAccess interface for consistency... Test script: --- $xml = 'foo'; $simple = simplexml_load_string($xml); var_dump($simple->item instanceof ArrayAccess); print (string) $simple->item[0]; Expected result: bool(true) foo Actual result: -- bool(false) foo -- Edit bug report at http://bugs.php.net/bug.php?id=52655&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52655&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52655&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52655&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52655&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52655&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52655&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52655&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52655&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52655&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52655&r=support Expected behavior: http://bugs.php.net/fix.php?id=52655&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52655&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52655&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52655&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52655&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52655&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52655&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52655&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52655&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52655&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52655&r=mysqlcfg
[PHP-BUG] Bug #52969 [NEW]: This defined in static call from within another class
From:
Operating system: linux
PHP version: 5.3.3
Package: Class/Object related
Bug Type: Bug
Bug description:This defined in static call from within another class
Description:
When calling a non-static method statically from within another class
(non-
inherited), $this is populated with the other object's class.
Test script:
---
class test1 {
public function getName() {
return $this->name;
}
}
class test2 {
public $name = 'foo';
public function getName() {
return test1::getName();
}
}
$obj = new Test2;
echo $obj->getName();
Expected result:
Fatal Error: Using $this when not in object context
Actual result:
--
"foo" is outputted.
--
Edit bug report at http://bugs.php.net/bug.php?id=52969&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52969&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52969&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52969&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52969&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52969&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52969&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52969&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52969&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52969&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52969&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52969&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52969&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52969&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52969&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52969&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52969&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52969&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52969&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52969&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52969&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52969&r=mysqlcfg
Bug #52969 [Opn]: This defined in static call from within another class
Edit report at http://bugs.php.net/bug.php?id=52969&edit=1
ID: 52969
User updated by:ircmaxell at yahoo dot com
Reported by:ircmaxell at yahoo dot com
Summary:This defined in static call from within another
class
Status: Open
Type: Bug
Package:Class/Object related
Operating System: linux
PHP Version:5.3.3
Block user comment: N
New Comment:
Oh, and $this is an object of class Test2 within Test1::getName()...
Previous Comments:
[2010-10-02 15:28:02] gnuffo1 at gmail dot com
This seems to have existed way back in PHP 4.1:
http://www.advogato.org/article/470.html
If this is a bug, then I think it should be turned into a feature and
documented. It is occasionally useful for trait-like functionality.
[2010-10-02 15:24:18] ircmaxell at yahoo dot com
Description:
When calling a non-static method statically from within another class
(non-
inherited), $this is populated with the other object's class.
Test script:
---
class test1 {
public function getName() {
return $this->name;
}
}
class test2 {
public $name = 'foo';
public function getName() {
return test1::getName();
}
}
$obj = new Test2;
echo $obj->getName();
Expected result:
Fatal Error: Using $this when not in object context
Actual result:
--
"foo" is outputted.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52969&edit=1
Bug #52969 [Bgs]: This defined in static call from within another class
Edit report at http://bugs.php.net/bug.php?id=52969&edit=1
ID: 52969
User updated by:ircmaxell at yahoo dot com
Reported by:ircmaxell at yahoo dot com
Summary:This defined in static call from within another
class
Status: Bogus
Type: Bug
Package:Class/Object related
Operating System: linux
PHP Version:5.3.3
Block user comment: N
New Comment:
Close it if you wish, but I do honestly believe this is a major bug...
This means that you cannot trust that $this is an instance of the class
it's
used in. So does that mean that we must add:
($this instanceof self) or throw new Exception('called from another
class');
to all of our methods?
Remember, any sufficiently advanced bug is indistinguishable from a
feature (no
matter if it is documented or not). But don't be afraid to call it what
it
really is... Just because it's documented, doesn't mean it isn't a
bug...
Again, IMHO...
Previous Comments:
[2010-10-02 20:07:43] cataphr...@php.net
Closing as bogus. As you have pointed out, this is documented.
[2010-10-02 15:51:04] gnuffo1 at gmail dot com
It has been pointed out to me that this is actually documented:
http://us2.php.net/manual/en/language.oop5.basic.php
Under example 2 and specifically the lines:
$b = new B();
$b->bar();
[2010-10-02 15:33:50] php at rwasmus dot nl
Can reproduce across architectures & versions from 5.2.9 onward, IMHO
opinion, just an E_STRICT error in between is understating the scripters
design flaw. Some existing code may rely on it, so a real fix may hurt
some packages, but at the very least I'd increase the errors severity.
----
[2010-10-02 15:33:00] ircmaxell at yahoo dot com
Oh, and $this is an object of class Test2 within Test1::getName()...
[2010-10-02 15:28:02] gnuffo1 at gmail dot com
This seems to have existed way back in PHP 4.1:
http://www.advogato.org/article/470.html
If this is a bug, then I think it should be turned into a feature and
documented. It is occasionally useful for trait-like functionality.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=52969
--
Edit this bug report at http://bugs.php.net/bug.php?id=52969&edit=1
Req #47802 [Com]: PDO_MYSQL doesn't use the charset parameter
Edit report at http://bugs.php.net/bug.php?id=47802&edit=1
ID: 47802
Comment by: ircmaxell at gmail dot com
Reported by:disbursement at dublin dot com
Summary:PDO_MYSQL doesn't use the charset parameter
Status: Closed
Type: Feature/Change Request
Package:MySQL related
Operating System: all
PHP Version:5.2.9
Assigned To:kalle
Block user comment: N
Private report: N
New Comment:
Re-opening this as it has security implications for 5.2.x. It should be
backported and re-released as a security fix for 5.2.x.
As it stands now, PDO::quote() does not protect against security
vulnerabilities
without the ability to set the character set in the C api. 5.3.6 closes
this
hole when supplied with the optional charset parameter (by appropriately
setting
the character set). However this will need to be expressed in the
documentation
(I will file another issue on this topic).
Proof Of Concept Code:
$dsn = 'mysql:dbname=INFORMATION_SCHEMA;host=127.0.0.1;charset=GBK';
$pdo = new PDO($dsn, $user, $pass);
$pdo->exec('SET NAMES GBK');
$string = chr(0xbf) . chr(0x27) . ' OR 1 = 1; /*';
$sql = "SELECT TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME LIKE ".$pdo->quote($string).";";
$stmt = $pdo->query($sql);
var_dump($stmt->rowCount());
Expected: int(0)
Actual: the number of tables on the server
Previous Comments:
[2011-01-17 11:46:00] ka...@php.net
Will appear in PHP 5.3.6 :)
[2011-01-17 10:54:23] ka...@php.net
Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revision&revision=307529
Log: MFT: Implemented FR #47802 (Support for setting character sets in
DSN strings)
[2011-01-07 18:18:31] ka...@php.net
Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revision&revision=307228
Log: Added test case for #47802 and fixed macro name after the move to
mysql_options()
[2011-01-07 15:40:32] ka...@php.net
Implemented in trunk for now
[2011-01-07 15:39:58] ka...@php.net
Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revision&revision=307224
Log: Implemented FR #47802, support for character sets in DSN strings
for PDO_MYSQL
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=47802
--
Edit this bug report at http://bugs.php.net/bug.php?id=47802&edit=1
Req #47802 [Com]: PDO_MYSQL doesn't use the charset parameter
Edit report at http://bugs.php.net/bug.php?id=47802&edit=1
ID: 47802
Comment by: ircmaxell at gmail dot com
Reported by:disbursement at dublin dot com
Summary:PDO_MYSQL doesn't use the charset parameter
Status: To be documented
Type: Feature/Change Request
Package:MySQL related
Operating System: all
PHP Version:5.2.9
Block user comment: N
Private report: N
New Comment:
I won't argue the decision, but I'd like to clarify one point. Right
now, in
5.2.x (and <=5.3.5) it's impossible to write a secure query using
PDO::quote. So
if you use another character set, it would automatically make all code
vulnerable
to SQL Injection (with no built-in method to fix it). So that leaves
existing
the code 3 options: Switch to MySQLi, Implement their own quoting
mechanism, or
switch to prepared statements (the best solution). But as it stands,
the API
does not deliver its promise.
Just an observation...
Previous Comments:
[2011-04-19 01:07:20] johan...@php.net
If a developer shots himself it is noting we can prevent. Tis does not
justify a security release of PHP as the only one who can exploit this
is the one writing code ...
This should however be made clear in the documentation: Executing SET
NAMES doesn't tell anything to the client library (libmysql / mysqlnd
used by PHP) so they can't do proper encoding. Therefore only Latin 1,
Utf-8 and other encodings using lower 7 bits in an ASCII compatible way
can be used safely. For other encodings the mentioned option, introduced
later in 5.3.6 should be used.
[2011-04-18 22:38:48] col...@php.net
Re-opening because of 5_2 backport request by some user.
----
[2011-04-18 22:34:03] ircmaxell at gmail dot com
Re-opening this as it has security implications for 5.2.x. It should be
backported and re-released as a security fix for 5.2.x.
As it stands now, PDO::quote() does not protect against security
vulnerabilities
without the ability to set the character set in the C api. 5.3.6 closes
this
hole when supplied with the optional charset parameter (by appropriately
setting
the character set). However this will need to be expressed in the
documentation
(I will file another issue on this topic).
Proof Of Concept Code:
$dsn = 'mysql:dbname=INFORMATION_SCHEMA;host=127.0.0.1;charset=GBK';
$pdo = new PDO($dsn, $user, $pass);
$pdo->exec('SET NAMES GBK');
$string = chr(0xbf) . chr(0x27) . ' OR 1 = 1; /*';
$sql = "SELECT TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME LIKE ".$pdo->quote($string).";";
$stmt = $pdo->query($sql);
var_dump($stmt->rowCount());
Expected: int(0)
Actual: the number of tables on the server
[2011-01-17 11:46:00] ka...@php.net
Will appear in PHP 5.3.6 :)
[2011-01-17 10:54:23] ka...@php.net
Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revision&revision=307529
Log: MFT: Implemented FR #47802 (Support for setting character sets in
DSN strings)
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=47802
--
Edit this bug report at http://bugs.php.net/bug.php?id=47802&edit=1
[PHP-BUG] Req #54638 [NEW]: PDO_MYSQL Always Uses Emulated Prepared Statements
From: Operating system: All PHP version: 5.3SVN-2011-04-30 (SVN) Package: PDO related Bug Type: Feature/Change Request Bug description:PDO_MYSQL Always Uses Emulated Prepared Statements Description: The PDO_MySQL driver defaults emulate_prepare to 1, which forces all prepared queries to be emulated by the driver. This means that even though the client library (mysqlnd or libmysql) may support prepared statements, PDO will never really use them. You can set the attribute PDO::ATTR_EMULATE_PREPARES to 0, and it prepares and executes the prepared statements just fine using the native mode (rather than emulation). However this is not documented at all on PHP.NET. Since PDO_MYSQL will fallback to emulation automatically if the client library or server are too old for prepared statements, I would suggest that the default value for emulate_prepare should be set to 0 to allow for true prepared statements. -- Edit bug report at http://bugs.php.net/bug.php?id=54638&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54638&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54638&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54638&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54638&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54638&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54638&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54638&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54638&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54638&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54638&r=support Expected behavior: http://bugs.php.net/fix.php?id=54638&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54638&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54638&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54638&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54638&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54638&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54638&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54638&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54638&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54638&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54638&r=mysqlcfg
[PHP-BUG] Bug #55168 [NEW]: mcrypt_create_iv uses E_ERROR on Win and E_WARNING on *nix
From: Operating system: Windows PHP version: 5.4SVN-2011-07-09 (SVN) Package: mcrypt related Bug Type: Bug Bug description:mcrypt_create_iv uses E_ERROR on Win and E_WARNING on *nix Description: If you call mcrypt_create_iv with either the MCRYPT_DEV_RANDOM or MCRYPT_DEV_URANDOM constants, and it cannot generate enough data, it issues an E_ERROR fatal error. However, on linux when the same situation it will just issue an E_WARNING. I suggest that it should be changed from an E_ERROR to an E_WARNING on Windows (as it certainly is recoverable). See: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/mcrypt/mcrypt.c? revision=311033&view=markup Specifically lines 1397 and 1422 -- Edit bug report at https://bugs.php.net/bug.php?id=55168&edit=1 -- Try a snapshot (PHP 5.2): https://bugs.php.net/fix.php?id=55168&r=trysnapshot52 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55168&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55168&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55168&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55168&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55168&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55168&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55168&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55168&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55168&r=support Expected behavior: https://bugs.php.net/fix.php?id=55168&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55168&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55168&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55168&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55168&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55168&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55168&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55168&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55168&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55168&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55168&r=mysqlcfg Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55168&r=trysnapshot54
