We are working on PCI compliance. Red flags are flying, most of which we can clear off with minor adjustments, sanitize some PHP form data coming in, turn off POP3 (we don't run mail ) etc..
but this one is troublesome: Audit report for one site show numerous risks that all start with:
"Description: PHP 5.3.x < 5.3.15 Description: PHP 5.3.x < 5.3.15 Multiple Vulnerabilities Synoposis: The remote web server uses a version of PHP that is affected by multiple vulnerabilities.[SNIP, long list of the specific vulnerabilities]"
so I went WebMin, Software Update packages and I see 213 updates are being offered for installation. That in itself is scary... but I assume I should run them all if security is important as many of these may be patches related to security... and i trust (hope!) that these upgrades will not break the OS....
BUT a PHP upgrade is not among them.
How should I proceed with a PHP upgrade? In the past we tried it and it failed and we had to regress. Since them they are now up to 5.4.X. I don't have test server I can work on. A search on the web shows PHP upgrades can be messy. I was hoping WebMin might be smart enough to do it for now in the end I believe it's just running YUM and then we pray for no conflicts.
Howdy,
Two thoughts regarding your questions --
First, you would want to regularly run a "yum update", to make sure you're running the latest CentOS packages.
Second -- if you were running PHP 5.3.3 directly from php.net, that would indeed be cause for concern. But that's not the case -- you're using a PHP version provided by CentOS/RHEL, and they backport security fixes into their PHP version.
That is -- CentOS ships with PHP 5.3.3, and that's the PHP version they keep in CentOS 6 for the life of the distro. Any security issues that come out -- they backport all the fixes into the PHP version they shipped.
So all outstanding security issues are patched -- there aren't any security issues that need corrected with the PHP version on your server (outside of simply running a "yum update" to make sure you have the most recent one).
PCI vendors should have an option for a "false positive" -- if you tell them you're using CentOS, your packages are up to date, and that there's no outstanding security issues, they should recognize that. There isn't an upgrade path on CentOS to get a more recent PHP version... outside of using a third party repository, which we'd highly recommend against.
-Eric
Eric: Thanks. That's exactly what I needed to hear.
re: Yum updates: when WebMin tells us "213" software packages to up date... do I need to do something special as a fail safe, or just hold my breath and tell them to run?
Restart the server when it's done? I'm not much of an expert on Unix Distro administration, so these things make me nervous. Generally speaking nothing bad happens, but I just want to know if there is some precautions that should be taken before running all these updates.
FYI: I'm pretty sure our web apps framework(s) and CMS(s) will have no problems with the upgrades that I can see.
do I need to do something special as a fail safe, or just hold my breath and tell them to run?
It never hurts to have a good solid backup before making a lot of changes :-)
But, so long as you're using just the standard CentOS and Virtualmin repositories, and no third party repositories, it should work well. You're installing highly tested packages.
Restart the server when it's done?
Only if you've installed a new kernel. It's not necessary to reboot for standard packages though, just a kernel update.
-Eric
I did it... from inside "Virtualmin Package Updates" module click update all... ten minutes later, last one....
Now updating yum-utils .. Installing package(s) with command yum -y install yum-utils .. [snip] Verifying : yum-utils-1.1.30-10.el6.noarch 2/2 Updated: Complete! .. install complete. Successfully installed 218 packages.
<- Return to package list
All is well, no one died (hehe) I see the option to auto update on a schedule. I set it to auto update weekly and notify me... i don't see any reason not to do that...
thanks, meanwhile I'm having a discussion next week with Security Metrics Scan admin about the PHP thing... yes, they did say they are open to discussion false positives, so hopefully they are savvy to CentoOS/php being safe.
Hi,
Do you know a way of getting the actual PHP version and not the one reported by PHP/CentOS?. For example, as Eric mentioned above:
That is -- CentOS ships with PHP 5.3.3, and that's the PHP version they keep in CentOS 6 for the life of the distro. Any security issues that come out -- they backport all the fixes into the PHP version they shipped. So all outstanding security issues are patched -- there aren't any security issues that need corrected with the PHP version on your server (outside of simply running a "yum update" to make sure you have the most recent one).
I have updated PHP today to:
php i686 5.3.3-22.el6
which indicates to me that I"m using PHP 5.3.22.
On my CentOS Virtualmin server, if I run a script to get the PHP version, PHP reports the following:
PHP_VERSION: 5.3.3
PHP_MAJOR_VERSION: 5
PHP_MINOR_VERSION: 3
PHP_RELEASE_VERSION: 3
php -v also shows:
PHP 5.3.3 (cli) (built: Feb 22 2013 02:37:06)
Do you know of anyway for PHP to get the actual version and not the version reported by the CentOS version of PHP including the backports and patches?
Thanks, Martin
phpinfo(); should get you pretty accurate results (I think)
But, I'm not an expert... I'm making an assumption that PHP itself should know all about itself... I could be wrong. So here's what I do:
Since it is considered a bad idea to expose this to the public/hackers/Russian Cyber Mafia :-) i usually will create a file in an obscure folder and call it something thing odd like
/public_html/obscure-folderGiantDolphin.php
and make sure there are no links to this on any pages on your site that bots or trolls could dig for. Then
put this into that file:
Now, run it from a browser: http://myDomain.com/obscure-folder/GiantDolphin.php
And you get a lot of interesting information. Save that as a file to your local hard drive for ref.
Depending on how paranoid you are you may want to remove that file and keep it on your local machine and only use it when you want to check up on the status of your PHP. I'm told that hackers, if they can review that information, could use to do "bad stuff"
Hi Katir,
That's my problem - the results shown above are from the following PHP script:
<?php
echo '<p>PHP_VERSION: ' . PHP_VERSION . '</p>';
echo '<p>PHP_MAJOR_VERSION: ' . PHP_MAJOR_VERSION . '</p>';
echo '<p>PHP_MINOR_VERSION: ' . PHP_MINOR_VERSION . '</p>';
echo '<p>PHP_RELEASE_VERSION: ' . PHP_RELEASE_VERSION . '</p>';
Outputs
PHP_VERSION: 5.3.3
PHP_MAJOR_VERSION: 5
PHP_MINOR_VERSION: 3
PHP_RELEASE_VERSION: 3
It's reporting 5.3.3, the same as phpInfo()
This is in relation to PHP not returning the correct version on CentOS as stated in my post.
Thanks, Martin
hmmm I did not read your first post too carefully. You said:
"php i686 5.3.3-22.el6
which indicates to me that I"m using PHP 5.3.22."
I think you meant to say "I'm using PHP 5.3.3-22"
there is a difference. My guess is that PHP considers any version that is
5.3.3-*[whatever build-patch number] as 5.3.3
One would need to got to the PHP forums to find out, what exactly constitute a true "dot upgrade" versus a patched build of the same version. I'm out of my depth on this.
katir, did you ever figure this out? We are in the same position... have run yum update and Virtualmin states no packages available, so all up to date. But PHP reports 5.3.3 so my PCI compliance is failing.
Try the following to see the exact version number and some other interesting install info
rpm -qa --qf '%{INSTALLTIME} (%{INSTALLTIME:date}): %{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' | sort -n | grep phpThe number aftet the
5.3.3.-indicates (roughly) the number of backports that Redhat did (especially security fixes).OK this worked... well I mean I got a nice report. I have yet to submit to the PCI auditor... hopefully they will accept the output and put a "white flag" on the "php is vulnerable" line
1329798205 (Mon 20 Feb 2012 08:23:25 PM PST): wbm-php-pear-1.5-1.noarch 1330123886 (Fri 24 Feb 2012 02:51:26 PM PST): php-mcrypt-5.3.3-1.el6.x86_64 1330620767 (Thu 01 Mar 2012 08:52:47 AM PST): php-pear-1.9.4-4.el6.noarch 1336003293 (Wed 02 May 2012 05:01:33 PM PDT): php-pear-Net-Socket-1.0.10-1.el6.noarch 1336003295 (Wed 02 May 2012 05:01:35 PM PDT): php-pear-Auth-SASL-1.0.4-1.el6.noarch 1336003297 (Wed 02 May 2012 05:01:37 PM PDT): php-pear-Net-SMTP-1.6.1-1.el6.noarch 1336003298 (Wed 02 May 2012 05:01:38 PM PDT): php-pear-Mail-1.2.0-1.el6.noarch 1336003299 (Wed 02 May 2012 05:01:39 PM PDT): php-pear-Net-DIME-1.0.2-1.el6.noarch 1336003300 (Wed 02 May 2012 05:01:40 PM PDT): php-pear-Net-URL-1.0.15-4.el6.noarch 1336003301 (Wed 02 May 2012 05:01:41 PM PDT): php-pear-HTTP-Request-1.4.4-2.el6.noarch 1336003304 (Wed 02 May 2012 05:01:44 PM PDT): php-pear-SOAP-0.12.0-4.el6.noarch 1350684750 (Fri 19 Oct 2012 03:12:30 PM PDT): php-pear-Mail-Mime-1.8.4-1.el6.noarch 1362902488 (Sun 10 Mar 2013 12:01:28 AM PST): php-common-5.3.3-22.el6.x86_64 1362902489 (Sun 10 Mar 2013 12:01:29 AM PST): php-pdo-5.3.3-22.el6.x86_64 1362902492 (Sun 10 Mar 2013 12:01:32 AM PST): php-cli-5.3.3-22.el6.x86_64 1362902493 (Sun 10 Mar 2013 12:01:33 AM PST): php-5.3.3-22.el6.x86_64 1362902495 (Sun 10 Mar 2013 12:01:35 AM PST): php-gd-5.3.3-22.el6.x86_64 1362902496 (Sun 10 Mar 2013 12:01:36 AM PST): php-mysql-5.3.3-22.el6.x86_64 1362902497 (Sun 10 Mar 2013 12:01:37 AM PST): php-odbc-5.3.3-22.el6.x86_64 1362902498 (Sun 10 Mar 2013 12:01:38 AM PST): php-pgsql-5.3.3-22.el6.x86_64 1362902499 (Sun 10 Mar 2013 12:01:39 AM PST): php-xml-5.3.3-22.el6.x86_64 1362902500 (Sun 10 Mar 2013 12:01:40 AM PST): php-xmlrpc-5.3.3-22.el6.x86_64 1362902501 (Sun 10 Mar 2013 12:01:41 AM PST): php-imap-5.3.3-22.el6.x86_64 1362902502 (Sun 10 Mar 2013 12:01:42 AM PST): php-snmp-5.3.3-22.el6.x86_64 1362902503 (Sun 10 Mar 2013 12:01:43 AM PST): php-mbstring-5.3.3-22.el6.x86_64 1362902503 (Sun 10 Mar 2013 12:01:43 AM PST): php-soap-5.3.3-22.el6.x86_64