On 2016-Sep-21 14:35, Adrian Sevcenco wrote:> On 09/21/2016 02:02 PM, ?????? wrote: > > Hello, > > > > 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. > > > > https://access.redhat.com/security/cve/cve-2016-4073 > > > > 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() > > function. > 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.> _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos
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: >>> Hello, >>> >>> 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. >>> >>> https://access.redhat.com/security/cve/cve-2016-4073 >>> >>> 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() >>> function. >> 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 plugin. 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 option. Stability is pointless when it doesn't serve the intended purpose. PHP even in CentOS 7 should be updated for a production server.
On 2016-Sep-21 11:00, Alice Wonder wrote:> 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 > plugin. > > 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 > option. > > Stability is pointless when it doesn't serve the intended purpose.Agree, but applications on my server work just fine with the old version. In case I need feature available only in the new version, I'd move to the new one. There is another CVE I'm having problem with. https://access.redhat.com/security/cve/cve-2015-8866 This one is still under investigation. I see Remi's comment in the bugzilla that it isn't really a security issue, but it's the Approved Scanning Vendors who should be convinced in that, and they mark it's PCI status as "fail". Anyone have any idea how to mitigate this issue? Some workaround?
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: >>>> >>>> Hello, >>>> >>>> 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. >>>> >>>> https://access.redhat.com/security/cve/cve-2016-4073 >>>> >>>> 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() >>>> function. >>> >>> 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 > plugin. > > 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 > option. > > 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 ... https://www.hogarthuk.com/?q=node/15 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.