updating to Apache to 2.2.16 and PHP 5.2.13 / 5.3.2

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

Joe's picture
Submitted by Joe on Wed, 10/13/2010 - 14:19 Pro Licensee

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.

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,

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.

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.

Joe's picture
Submitted by Joe on Wed, 10/13/2010 - 16:34 Pro Licensee

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. ;-)

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.so

I updated the latest PHP bleed patches and Appealed. I'll let you know what is the response on it.

Thank you

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.

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.

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?