+++ This bug was initially created as a clone of Bug #24165 +++
a new update is released, which fixes many buffer overflow issues in gd, mbstring, phar and xmlrpc
Updated php packages fix security vulnerabilities:
Several buffer overflows in the components GD, MBString, Phar and XMLRPC were discovered and fixed.
Updated packages in core/backports_testing:
RPM Packages =>
Installed and tested without issues.
Tested with various large (e.g. wordpress, drupal, roundcubemail) and small scripts, using HTTP(S) and CLI. Also tested the various PoC.
System: Mageia 6, x86_64, Intel CPU.
Details of system and tests are here:
Mageia 6, x86_64
Tested PoCs before and after updates. Details on https://bugs.mageia.org/show_bug.cgi?id=24165 comments 3 to 9. There is still some doubt over one failed PoC test, failed in the sense of showing no change before and after updates.
strange: when I run the test with php-phar-7.2.13-2.mga6, I get:
$ USE_ZEND_ALLOC=0 php -r "var_dump(new Phar(file_get_contents('poc.phar'),0,'test.phar'));"
PHP Fatal error: Uncaught UnexpectedValueException: Cannot create a phar archive from a URL like "
with php-phar-7.2.14-1 I get the same result. But this looks good, no?
(In reply to Marc Krämer from comment #4)
> strange: when I run the test with php-phar-7.2.13-2.mga6, I get:
> $ USE_ZEND_ALLOC=0 php -r "var_dump(new
> PHP Fatal error: Uncaught UnexpectedValueException: Cannot create a phar
> archive from a URL like "
To test this PoC, PHP needs to be built with AddressSanitizer enabled and that is probably not the case for this build.
@Marc. Yes it is probably OK. PC LX points out that the asan framework is used upstream, as it often is for POC tests involving memory leaks, buffer overflows and the like. If there is a difference in the results for our builds that could be interpreted as good, epecially if say a crash is avoided in the after test, or if they are the same and the diagnostics seem to show that errors are being handled properly that is also good. For testers it is not really a precise science. My doubt, expressed in comment 3, was because the error did not look as if it had been caught, but if it worked for you...
ok, thanks for the tests! So I hope we can move on :)
Of course, 64-bit OK coming up.
Two (!) 64-bit tests = validation.
I am uneasy about these backports which incorporate security & bug fixes not (I think) having advisories. We must clarify that. Maybe they are optional.
@Lewis: sorry I did not get your point. What do you think is still needed to be clarified - or done before?
Do you think an advisory for a backported package should be published? If so, I think you're right. I think backports should have an advisory, if we push an security update.
(In reply to Marc Krämer from comment #11)
> @Lewis: sorry I did not get your point. What do you think is still needed to
> be clarified - or done before?
We need to clarify whether Backports require advisories, or not; or whether they *can* have one even if not strictly required. My understanding is that they do not have advisories; but I think they should. There has to be a reason for a backport; why not tell the users? I have omitted, for validated backports, a few that looked rather important.
> Do you think an advisory for a backported package should be published? If
> so, I think you're right. I think backports should have an advisory, if we
> push an security update.
Or bugfixes. We both agree, but this is just a matter of our opinion. Seeing that tmb has added himself to this bug, he will doubtless advise us!
(In reply to Lewis Smith from comment #13)
> Or bugfixes. We both agree, but this is just a matter of our opinion. Seeing
> that tmb has added himself to this bug, he will doubtless advise us!
Late to the party... it was/is planned to have advisories for backports, but since no-one have had time to extend mga-advisories to handle backports, currently we just move the packages...