PHP’s implementation of crypt_blowfish differs from the upstream Openwall
version by adding a “PHP Hack”, which allows one to cut short the BCrypt salt
by including a `$` character within the characters that represent the salt.
Hashes that are affected by the “PHP Hack” may erroneously validate any
password as valid when used with `password_verify` and when comparing the
return value of `crypt()` against the input.
The PHP Hack exists since the first version of PHP’s own crypt_blowfish
implementation that was added in 1e820eca02.
No clear reason is given for the PHP Hack’s existence. This commit removes it,
because BCrypt hashes containing a `$` character in their salt are not valid
BCrypt hashes.
Commit fbe3059 included an unintended change to the test which checks if
dns_get_record populates its additional parameter. This patch reverts
such change.
The issue was not detected by the CIs because their tests run in
the --offline mode, and the test in question needs internet connection.
Closes GH-9625.
While the reason-phrase in a HTTP response status line is usually
short, there is no actual limit specified by the RFCs. As such, we
must not assume that the line fits into the buffer (which is currently
128 bytes large).
Since there is no real need to present the complete status line, we
simply read and discard the rest of a long line.
Co-authored-by: Tim Düsterhus <timwolla@googlemail.com>
Closes GH-9319.
This fix is another solution to replace d0527427be, use zend_try and zend_catch to make sure persistent stream will be released when error occurred.
Closes GH-9332.
The comparator function used at ksort in SORT_REGULAR mode
need to be consistent with basic comparison rules. These rules
were changed in PHP-8.0 for numeric strings, but comparator
used at ksort kept the old behaviour. It leads to inconsistent
situations, when after ksort the first key is GREATER than some
of the next ones by according to the basic comparison operators.
Closes GH-9293.
Not such as fix but taking more precautions.
Indeed, the arc4random has two little flaws in this platform,
one already caught upfront by the extension (ie size 0), also
internal use of ccrng_generate which can silently fail in few rare
cases.
Closes#7824.
We explicitly check for an exception after the logging attempt, and
bail out in that case.
Co-authored-by: Tim Düsterhus <timwolla@googlemail.com>
Closes GH-7878.
Since we're going to read from the current stream position anyway, the
`max_len` should be the size of the file minus the current position
(still catering to potentially filtered streams). We must, however,
make sure to cater to the file position being beyond the actual file
size.
While we're at, we also fix the step size in the comment, which is 8K.
A further optimization could be done for unfiltered streams, thus
saving that step size, but 8K might not be worth it.
Closes GH-7693.
Make sure to destroy the old value only after assigning the new
one. Otherwise we may try to double free, e.g. if GC runs during
this dtor.
This caused an assertion failure in phpro/grumphp and is likely
the cause for bug #81603 as well.
(cherry picked from commit 6f38acfaf9)
(I applied this to the wrong base branch at first...)
Make sure to destroy the old value only after assigning the new
one. Otherwise we may try to double free, e.g. if GC runs during
this dtor.
This caused an assertion failure in phpro/grumphp and is likely
the cause for bug #81603 as well.
Modify dns_get_record to test for records result based on dns_errno to
accommodate modern FreeBSD, for which res_nsearch() does not update
h_errno directly. Add new php_dns_errno macro, and have it consult
statp->res_h_errno when OS has res_nsearch().
Closes GH-7655.
While it may not be desired, `DateInterval::$f` supports negative
values, at least with regard to calculations. We still need to guard
from assigning double values which are out of range for signed 64bit
integers (which would be undefined behavior). zend_dval_to_lval() does
this by returning `0` instead of triggering UB. This way we can avoid
setting the invalid marker, which doesn't work as expected anyway.
We must not do that only for unserialization, but also when the property
is set in the first place.
We need to adapt some of the existing tests wrt. this behavior. In
particular, we check for an arbitrary value in bug79015.phpt, to cater
to differences between 32bit and 64bit architectures.
Closes GH-7575.
Don't allow calling fclose() on the stream while in the user
filter callback. This is basically the same protection as xp_ssl
streams use during callback invocations.
There are more issues in this general area (e.g. stack overflow
on stream_filter_remove), but this addresses freeing the stream
during the filter callback invocation at least.
Change error message of sprintf/printf for missing/invalid position
specifier to make it clear that this is talking about the specifier,
not the number of arguments passed to the function. Also mention
the upper limit of INT_MAX.
Closes GH-7515.
Test case "ext/standard/tests/array/range.phpt" failed on ARM64 machine
only under RELEASE mode.
How to reproduce it:
```
./buildconf -f; ./configure; make -j 128
make test TESTS="-d opcache.enable=1 -d opcache.enable_cli=1 ext/standard/tests/array/range.phpt"
```
Root cause:
I suspect the root cause is that on ARM64 machine, PHP RELEASE mode
produces different values for internal function range() compared to
DEBUG mode.
Take the downsized test case downsize-range.php [1] as an example. We
applied the check-element.diff patch to check the original values. Note
that we print out the floating point numbers with precision 16.
From the outputs in file output.md, we can see the 7-th and 9-th
elements are different between RELEASE and DEBUG.
To be honest, I didn't get where such difference comes from and probably
this is due to different compilation options used by RELEASED and DEBUG.
Fix:
After commit [2], serialize_precision is used for var_dump(). As a
result, the pre-set "precision=14" didn't work actually.
In this patch, we turn to set serialize_precision as 14 and therefore
the difference between RELEASE and DEBUG can be eliminated.
Note-1: this failue didn't occur on x86 machine.
Note-2: in my local test, this is the only test case which behaves
differently on ARM64 machine under RELEASE and DEBUG mode.
[1] https://gist.github.com/shqking/0d55abf8dbaafde4a00ea9304e71f06b
[2] a939805
Change-Id: I9293e990925590f8d7cfb2462d8d760abf76069f
If we assemble a zend_string manually, we need to end it with a NUL
byte ourselves.
We also fix the size calculation for that zend_string; there is no need
for the extra byte for each part, and we don't have to multiply by two,
since we're using DnsQuery_A(), not DnsQuery_W () (in which case we
would have to do the character set conversion, anyway). This avoids
over-allocation, and the need to explicitly set the string length.
Finally, we use the proper access macro for zend_strings.
Closes GH-7427.
