How does one upgrade to the latest packages, they are not the latest in my package list (specifically PHP)

Virtualmin
1

HI
I have Centos 6.3. I understand Centos does not update often or include the latest versions.

Well, my PCI scanning failed and one of them is because of a vulnerability in PHP version I have and that it was fixed in PHP 5.3.6 and another fix in PHP 5.3.7.

So I want to upgrade to the latest 5.3.

But the package list is stating the latest is 5.3.3-22.

I cannot find any info on this on the forum/docs. The bleeding edge documentation find is old or related to Centos 5.

So how would I upgrade just the various packages I need to, in this case PHP to the latest 5.3, and I may have other packages as I work down the PCI report.

Thanks a lot

2

I found this thread which explains about the latest updates are actually included in latest Centos package updates (I am up to date via “yum update”), so I understand that. Although find it strange they would not update the versions.
http://www.virtualmin.com/node/23688

problem is I have so many fails in the PCI scan, I could report them as backported/false positives, but I have to read every single one, make sure it is referring to PHP/Apache versions, then dispute it. This takes ages.

ideally we need the PCI scans to automatically pass the server based on packages being up to date. How would we make sure PCI automatically scans so we dont need to review and dispute every fail?

Thanks

3

You can configure PHP to not give out any info, this will cloak the version number. The same can also be done for Apache, which has a similar issue.

4

I have now disabled showing PHP and Apache versions in the header, and this actually worked for most points. Thats good. I am quite amazed it passes PCI due to hiding version number, because in theory I could have an older version with the issues!

But there is one issue with versioning still:
Apache HTTP Server Overlapping Byte-Range Denial of Service

The report states this was fixed in Apache 2.2.20. The report also states vendors have back ported the fixes, but the fact that the “Apache HTTP Server responded to an HTTP request in a way that indicates that it is likely vulnerable to a Denial of Service attack”, tells me that the version of Apache I have has NOT had backported fixes, so therefore I guess my original question still stands for Apache, I would need to upgrade Apache to at least 2.2.20 but thats not in the package list to update, it says I am all up to date.

Thanks

5

The security CVE in question is CVE-2011-3192

So I ran:
rpm -q --changelog httpd | grep CVE-2011-3192

And I get:

  • add security fix for CVE-2011-3192 (#733063, #736592)

So it seems the security fix IS in the Apache I am running, yet PCI states I have an issue with this CVE. I dont get it :frowning:

6

Seems the Apache Range exploit can be disabled in .htaccess, so I added this:

RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
RewriteRule .* - [F]

Then I used this site to test if its fixed:
http://apache-range-exploit.com/

It is now fixed (it was not fixed before the code added to htaccess).

I am running PCI scan again.

But what confuses me is why the server reports the CVE has beed added, yet the Range exploit still exists.

I also dont know if this fix has any disadvantage on the site, i.e. block legitimate requests

7

Open SSH is another one, fails on CVE-2010-4755, but this does not seem to be backported as its not in the changelog…

Running version: OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010

rpm -q --changelog httpd | grep CVE-2010-4755
No results

I hate this version number not changing, seems a nightmare to find out what actual version you are in if you include backports.

8

Howdy,

Once distribution vendors release a given distro version, they don’t change any of the software versions in it – those software versions are set in stone once the distribution is released.

That greatly increases stability, and makes sure that once an application is designed to be able to run on that platform, it’ll continue to do so, without behind hindered by the bugs that could be introduced by changing software versions :slight_smile:

Backporting can make figuring out the requirements of PCI scanners a pain. Without backporting though, it’s really not, in our opinion, a stable server platform :slight_smile:

The problem with the SSH issue you mentioned is that it’s a DoS against the client by a malicious server. And that the issue only appears to affect BSD.

That may mean that your vendor is just looking at all the CVE’s that have been fixed in recent software versions, whether or not they actually apply to you.

You can see RedHat’s comment on the issue here, where they say it’s not actually a server security issue:

https://access.redhat.com/security/cve/CVE-2010-4755

And the mailing list here describes the problem in a bit more detail:

http://www.gossamer-threads.com/lists/openssh/dev/51467

I know it’s a pain, but stick to your guns with your PCI vendor – tell them you’re using the most recent packages available in your distro, and that all relevant CVE’s have fixes that have been applied. In the case of CVE-2010-4755, that’s not a security issue (since it’s a way for malicious servers to DoS clients), and it also doesn’t apply to Linux servers, only BSD.

-Eric

9

Thanks a lot for your explanation. I dont think I need to fix the Openssh issue to pass PCI, it was just the highest severity, but turns out not the reason I am failing so will leave that.

The only point left why I am failing is the database port is open. The problem is we have a firewall that blocks all ports unless its an approved IP, and have had to add them as approved IP for their scans, but then they fail because they can see the port open! So I have asked CSF support if I can block ports to approved IPs, and asked Trustwave to pass it based on this.

I just want an automated pass, I dont want to have to keep disputing things!

Thanks for your help, fingers cross nearly there.