Submitted by mseslija on Wed, 10/13/2010 - 13:56
Hi,
I wanted to update the Apache and PHP Because of PCI.
I tested this with an Apache 2.2.16 RPM:
yum localinstall httpd-2.2.16-1.i386.rpm Loaded plugins: fastestmirror, priorities Setting up Local Package Process Examining httpd-2.2.16-1.i386.rpm: httpd-2.2.16-1.i386 httpd-2.2.16-1.i386.rpm: does not update installed package.
Nothing to do
and it didnt work,
Can you please let me know how I can update the Apache and PHP.
Thanks,
Mladen
Status:
Active
Comments
You shouldn't, if you're just doing it for PCI compliance.
The versions provided by CentOS/RHEL have all security patches applied. It is entirely possible to be PCI compliant with the stock CentOS/RHEL packages, and I strongly recommend you do so (they are better tested and probably more stable then the latest version). Also building from source to get the latest version is just asking to get in trouble one day when you forget which software is installed from source and a security vulnerability occurs. With standard packages, you'll get notified of the updates in your Virtualmin front page, but it can't tell you about source-installed software.
We provide bleeding edge PHP packages, as documented here: http://www.virtualmin.com/documentation/system/bleed
But, I really don't recommend going off the standard versions, if you don't need it for a specific application.
Submitted by mseslija on Wed, 10/13/2010 - 15:21 Comment #2
Hi,
As you are recomending to not update the packages, I tried to apply patches on them and do Apeal. It got denied. The details are bellow. What would be your suggestions to pass this PCI scan without the updating? I did got simmilar response for Apache as well.
I did submit Apeal to PCI Tester -Trust Keeper
"5.2.10-1.el5.centos
The server is running CentOS 5.5 and has been updated to the latest version of all available packages from Redhat using YUM"
TrustKeeper Response:
"We have denied this appeal based on the information provided indicating that php-5.2.10-1.el5.centos is in use. It has not been confirmed that this version addresses CVE-2010-1129, CVE-2010-1128, and CVE-2010-1130. Please lookup these CVE's at https://www.redhat.com/security/data/cve/. Redhat claims that CVE-2010-1129 and CVE-2010-1130 are not security issues (and CVE-2010-1128 appears not to have yet been addressed by Redhat) while the PCI Security Standards Council states that they are, as such they would need to be addressed in some fashion."
Thanks,
Submitted by mseslija on Wed, 10/13/2010 - 16:03 Comment #3
Here are the details for the Apache apeal denied
httpd-2.2.3-43.3.vm (Apache/2.2.3)
Explanation/Evidence: The server is running CentOS 5.5 and has been updated to the latest version of all available packages from Redhat using YUM. Although the verions numbers are not the latest, all security updates have been backported into the RPMs as per RedHats standard backporting procedures.
Response Date Oct 13, 2010
Appeal/Repeal Status: Denied
Response: We have denied this appeal based on the information provided indicating that httpd-2.2.3-43.3 is in use. While this version may have addressed CVE-2008-2364, it has not been confirmed that CVE-2007-6420 has been addressed. Please refer to http://www.redhat.com/security/data/cve/CVE-2007-6420.html. Redhat claims that this CVE is not a security issue while the PCI Security Standards Council states that it is, as such the issue would need to be addressed in some fashion.
Submitted by JamieCameron on Wed, 10/13/2010 - 16:07 Comment #4
I'd agree with redhat here - this isn't a security hole.
And if it bothers your auditors, you could turn off mod_proxy_balancer.
I did submit Apeal to PCI Tester -Trust Keeper
"5.2.10-1.el5.centos
The server is running CentOS 5.5 and has been updated to the latest version of all available packages from Redhat using YUM"
Whoah! This is not the RHEL/CentOS official package.
The httpd package is one of ours, and it is based on the RHEL/CentOS package of the same version (with only a configuration option altered).
So, I would recommend you get rid of whatever repository is providing your PHP package. I have no idea where it came from or what its history is. Revert back to the official RHEL/CentOS PHP version. And then, maybe switch PCI compliance testing companies to one that's not insane. ;-)
Actually, I'll have to look into this a bit. I have no idea. Tons of Virtualmin users have successfully undergone PCI compliance testing with the stock CentOS/RHEL packages (and our vm version of the httpd package). I trust the RHEL security folks more than I trust the PCI testing folks, by a large margin. ;-)
Submitted by mseslija on Fri, 10/15/2010 - 08:33 Comment #6
For the Apache, I disabled the following modules and it pass the PCI.
LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_balancer_module modules/mod_proxy_balancer.so LoadModule proxy_ftp_module modules/mod_proxy_ftp.so LoadModule proxy_http_module modules/mod_proxy_http.so LoadModule proxy_connect_module modules/mod_proxy_connect.so LoadModule proxy_ajp_module modules/mod_proxy_ajp.soI updated the latest PHP bleed patches and Appealed. I'll let you know what is the response on it.
Thank you
Submitted by mseslija on Fri, 10/15/2010 - 12:01 Comment #7
Patched Service
Appeal Follow-up: Please provide current patch level (patch name or equivalent version number).
5.2.11-1.el5
Explanation/Evidence:
The server is running CentOS 5.5 and has been updated to the latest version of all available packages. Although the verions numbers are not the latest, all security updates have been backported into the RPMs as per RedHats standard backporting procedures
Response Date Oct 15, 2010
Appeal/Repeal Status: Denied
Response: We have denied this appeal based on the information provided indicating that php-5.2.11-1.el5 is in use. It has not been confirmed that this version addresses CVE-2010-1129, CVE-2010-1128, and CVE-2010-1130. Please lookup these CVE's at https://www.redhat.com/security/data/cve/. Redhat claims that CVE-2010-1129 and CVE-2010-1130 are not security issues (and CVE-2010-1128 appears not to have yet been addressed by Redhat) while the PCI Security Standards Council states that they are, as such they would need to be addressed in some fashion.
Submitted by mseslija on Fri, 10/15/2010 - 12:07 Comment #8
We have denied this appeal based on the information provided indicating that php-5.2.11-1.el5 is in use. While this version may have addressed many of the CVE's associated with this finding it has not been confirmed that CVE-2009-3557, CVE-2009-3558, and CVE-2009-4143 have been addressed. Please lookup these CVE's at https://www.redhat.com/security/data/cve/. Redhat claims that these CVE's are not a security issue while the PCI Security Standards Council states that they are, as such the issues would need to be addressed in some fashion.
Submitted by mseslija on Fri, 10/15/2010 - 13:28 Comment #9
We have denied this appeal based on the information provided indicating that php-5.2.11-1.el5 is in use. While this version may have addressed CVE-2010-2225 it has not been confirmed that CVE-2010-0397, CVE-2010-1860, CVE-2010-1862, CVE-2010-1864, CVE-2010-2097, CVE-2010-2100, CVE-2010-2101, CVE-2010-2190, CVE-2010-2191, CVE-2010-2484, , CVE-2010-2531, and CVE-2010-3065 have been addressed. Please lookup these CVE's at https://www.redhat.com/security/data/cve. While Redhat may not yet have patched some of these issues (and/or does not consider some of these CVE's to be serious security issues) the PCI SSC states that they are PCI non-compliant issues and as such they would need to be addressed in some fashion.
These arre the 3 issues I got for the PHP.
Any suggestions on it?