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.
Thanks!
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 ..
HTH, Adrian
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@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@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.
On 09/23/2016 04:42 AM, James Hogarth wrote:
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 ...
James, let me start out by saying that I greatly appreciate your work in and with EPEL. It is fantastic. And even in the context of what I write below I am a mostly satisfied user of EPEL7; there are just a few rough edges (and core policies) that are becoming increasingly annoying.
What I am about to suggest is likely to be rather controversial. If the upstream RHSCL cannot be used, then why can't EPEL be built against CentOS and then use the CentOS SCL to fix this issue?
EPEL7 is nowhere near as useful as it could be due to versioning policy and due to the upstream EL7 being so inflexible in versioning. Case in point is boost, where EL7's 1.53 is just barely too old for lots of highly useful workstation packages (such as KiCAD, which needs 1.54+). A software collection is the correct way to do up boost 1.54 for a KiCAD 4.x package for EL7 (CentOS and SL both), but a quick perusal of the current SCL shows that boost 1.54+ is a requirement for at least two already supported SCL packages.
In my opinion, the versions of packages that are supported should be user-needs driven and not so inflexible that, for instance, an easy upgrade of GNURadio to the latest version from the quite old version supported in EPEL7 would be done, simply because most enterprise users of GNURadio are going to need the latest version regardless of the packaging and versioning guidelines.
Or, in summary, stability should not be equated with version stagnation, IMHO. As always, I reserve the right to be wrong, etc. And maybe it is time to get back on the Fedora ratchet on the workstation; not something I'm looking forward to. At least the Fedora ratchet steps are smaller than the EL steps, even if they are closer together. Software Collections helps a great deal, especially in the server space, but there is just way too much inflexibility in some of the policies to find that happy medium between 'stable' and 'usable.' And as the update release versions climb above x.3, it gets harder. Lots harder. And at x.8 it gets nearly impossible; I'm migrating my work's ownCloud to C7 from the rock-solid C6 box entirely due to PHP versioning issues with an ownCloud app we want to use, which requires PHP >=5.5 (Software Collections for C6 gets us to PHP54; SCL for C7 goes farther).
After all, I bought my used Dell Precision M6500 mobile workstation specifically because it is certified for Red Hat Enterprise Linux use (most of the Precision mobile workstations can be ordered from Dell with an RHEL subscription as an equally-well-supported OS option to Windows). CentOS 7 is perfectly at home on it, and all typical 'laptop' features that I use just work right out of the box.
If EPEL could build against and require packages in SCL (like the case of ownCloud; ownCloud's own community packages are available for C6 PHP54_SCL that are now working very well at the 9.1.1 level) that would make it some easier for users, but it is likely to run way afoul of EPEL's rather restrictive policies. Barring that, I believe that ownCloud and Nextcloud could be built in SCL itself relatively easily, although that is essentially what ownCloud (but not Nextcloud) is already doing.
On 09/24/2016 07:40 AM, Lamar Owen wrote:
On 09/23/2016 04:42 AM, James Hogarth wrote:
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 ...
James, let me start out by saying that I greatly appreciate your work in and with EPEL. It is fantastic. And even in the context of what I write below I am a mostly satisfied user of EPEL7; there are just a few rough edges (and core policies) that are becoming increasingly annoying.
What I am about to suggest is likely to be rather controversial. If the upstream RHSCL cannot be used, then why can't EPEL be built against CentOS and then use the CentOS SCL to fix this issue?
That's effectively what I do with https://librelamp.com/ and https://media.librelamp.com/
I started just building newer PHP versions, then moved to building them against LibreSSL and building newer versions of some of the other packages against LibreSSL.
Building against LibreSSL allowed me to have some of the OpenSSL features not in the CentOS OpenSSL packages without needing to package them in /opt or /usr/local - which was very useful for building the bitcoin client but also useful for the ChaCha20/Poly1305 ciphers that are of benefit to mobile users (provides forward secrecy with less resources than AES for mobile clients w/o AES hardware assistance)
With PHP it not only gave me access to newer versions of PHP but to the full set of modules readily available to Fedora users, and things like WebP support in ImageMagick.
With Apache, it allowed me to offer the latest w/ HTTP/2 support and do some tweaks like completely disable some of the dangerous ciphers in mod_ssl so that a default install gets an "A" grade from ssllabs even before tweaking. Defaults that weren't thought to be dangerous when the Fedora package that eventually became the RHEL package were created.
The obvious downsides, my packages aren't as well tested before pushed and I can't guarantee a security response in a timely manner, though I have been pretty good often beating the RHEL/CentOS packaging of a fix - but I can't guarantee that.
Just last month I was working on my VLC package for my media repository and I rebooted to see if I could get bluray to work, probably didn't need to reboot since nothing kernel was involved but a kernel update had come in, and the PC wouldn't boot - the error beeps indicated a corrupted bios (not from anything I did), trying to flash the bios didn't work, and I was stuck doing any and all package building on a Thinkpad T410 (I refuse to do package building on a linode VM for security reasons), just finally built a new workstation last weekend.
But point is, I can't recommend my packages to anyone where delays in updates or bugs from reduced packaging may result in financial loss.
But I definitely hear where you are coming from, and agree that in many cases updates to what is in RHEL/EPEL are very beneficial.
It also can be confusing, there's a sound card I want but it requires a 3.17 kernel and I simply don't know if the drivers have been backported into RHEL/CentOS 3.10 or if they are available in elrepo - without the sound card physically installed I can't do an lspci to find out if the driver is available. It's tempting to try to create a kernel repo that has newer versions of the kernel but with RHEL specific patches and configurations applied, but I'm afraid there, the benefit wouldn't really be worth the work (e.g. USB sound cards work just fine, I just want inexpensive low profile PCI-E with optical out to reduce cable mess)
I think RHEL/CentOS is a great starting point for stability but I guess I'm saying I am definitely in favor of special use repositories for cases like the server stack or the multimedia stack where there are definite benefits to running newer versions.
And IMHO they should be special purpose repositories that require EPEL and are used only when that purpose is needed, rather than a general purpose single repository. Let EPEL be the general purpose add-on repository.
https://pci.qualys.com/static/help/merchant/questionnaires/compensating_cont...
Eero
2016-09-21 14:02 GMT+03:00 Прокси proxy-one@mail.ru:
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.
Thanks! _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 2016-Sep-21 14:45, Eero Volotinen wrote:
https://pci.qualys.com/static/help/merchant/questionnaires/compensating_cont...
Eero
Well, I was hoping to get some ideas for compensating controls in this case. Anyhow, I just added mb_strcut() to disable_functions. I'll be able to live without it.
2016-09-21 14:02 GMT+03:00 Прокси proxy-one@mail.ru:
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.
Thanks! _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-
Adrian Sevcenco -
Alice Wonder -
Eero Volotinen -
James Hogarth -
Lamar Owen -
Прокси