[CentOS] PHP vulnerability CVE-2016-4073
james.hogarth at gmail.com
Fri Sep 23 08:42:22 UTC 2016
On 21 September 2016 at 19:00, Alice Wonder <alice at domblogger.net> wrote:
> On 09/21/2016 05:43 AM, Прокси wrote:
>> On 2016-Sep-21 14:35, Adrian Sevcenco wrote:
>>> On 09/21/2016 02:02 PM, Прокси wrote:
>>>> My server with CentOS 6.8 just failed PCI scan, so I'm looking into
>>>> vulnerable packages. PHP 5.3.3 have multiple vulnerabilities, some of
>>>> them are fixed/patched or have some kind of workaround. But I can't find
>>>> a way to fix this one. Red Hat state: under investigation.
>>>> This CVE is 6 months old, and it doesn't look like it will be fixed.
>>>> Does anyone knows the way to go around this? Except blocking mb_strcut()
>>> you could try the unsupported php from remi repos... you can find there
>>> php 7.0 ..
>> I use CentOS because I need stable and patched packages, so I can be
>> sure that all applications work without unpleasant surprises. Going to
>> unsupported packages would be my last option.
> I feel the same way but I find that it is generally safe and beneficial to
> update the LAMP stack on servers and the multimedia stack on the desktop.
> Things like HTTP/2 are not available in the Apache that ships even with
> CentOS 7 and the PHP is so outdated that it causes problems when using third
> party projects because the developers of those projects aren't using
> anything that old anymore. And for the TLS stack, mobile really benefits
> from chacha20 ciphers.
> With respect to multimedia, there's the fluendo codec pack but interestingly
> FireFox won't play mp3 with the fluendo codec pack, it wants the libmad
> And even more bizarre, maybe they have fixed it, but GStreamer 1.x in CentOS
> 7 when it shipped was not capable of decoding the VP9 codec used in WebM2.
> CentOS 7 came with tools to encode VP9 but the GStreamer was too crusty to
> decode it, and the commercial fluendo plugins were of no help there -
> replacing the GStreamer 1.x packages with a modern build was the only
> Stability is pointless when it doesn't serve the intended purpose.
> PHP even in CentOS 7 should be updated for a production server.
Of course this is where Red Hat intends SCL to fill the gap of the
"supported" new httpd24 and php56 on RHEL ...
Unfortunately this is having a knock on effect in the EPEL world
where, since Fedora has no SCL packaging guidelines and RHSCL is not
included in repos EPEL can get built against, we can't package any
applications there that need the newer functionality from RHSCL ...
If, for example, ownCloud were to raise their minimum PHP requirements
from 5.4 to 5.6 (which honestly would be reasonable at this point) I'd
have no choice but to retire the ownCloud packages from EPEL7, just
like I had to retire it from EPEL6 with the PHP5.3 limitation there.
More information about the CentOS