PHP upgrade

I don’t know if this is the correct location for this. If not where?

The stat auditors complained that one of my web servers had security holes. One of them being PHP. I current have PHP 5.2 that came with the install disk. I cannot figure out how to upgrade the server to php 5.5.

Thanks
Dave.

Which version of SLES are you using?

Did these auditors specify what about your PHP installation is insecure, or did they just point at a version number?

Have you installed all outstanding updates? SUSE do release security fixes for PHP. (e.g. http://download.novell.com/Download?buildid=fEgFplF5M_0~)

There are SUSE SLE-11 SP 3 packages for PHP 5.5 available from http://software.opensuse.org/package/php5 but they are not supported.

I am using SUSE SLE-11 SP 3

This is all I have received from the I.T. director.

"
I need something addressed immediately.
Our state auditor did a security scan on hosts on our network and found 1 critical, 3 high and 4 medium severity threats on the BCI server:
http://bcd.school.edu/dep_home.php

I need to have the necessary updates performed on it right away. He will be rerunning this on Monday and will result in an audit comment or finding if it isn’t resolved.

This includes unsupported versions of PHP and many, vulnerabilities associated with the old version.
"

This is not a critical server. It is one I use in training interns. I turned off the firewall the other day to do some trouble shooting. I turned it back on today. So that may have fixed a few problems. But with the exception of PHP I have no idea what needs to be fixed. I can’t get anyone to talk to me. Our school is shutdown today.

Thanks

You need to get the actual audit report. Many auditors take advantage of
the easiest way to get exceptions for their reports by scanning for
versions of software, since vulnerabilities are discovered in version (for
example) 5.3 and then are known to exist in 5.2, 5.1, etc. By looking and
seeing you are not yet on 5.5 they can claims you are vulnerable to
everything pre-5.5 and give you a long list, using lots of pages of a
document, and seeming to earn lots of money.

The problem is that version numbers are nothing more than integers, and
enterprise distributions of Linux like SUSE Linux Enterprise backport
fixes into older version numbers. This is done so that when you get the
latest patches of SLES you get fixes, even those from future versions of
packages like PHP, but without getting potentially less-stable code from
new features in PHP. The result is that auditors who cannot actually test
for vulnerabilities but can only test for certain versions of software are
not valuable and are not giving you accurate information, other than “Your
package version is older than something new.” which of course you know and
is irrelevant to anything security-related.

On the other hand, if their tests actually attempted to exploit
vulnerabilities and were able to somehow then there should be bugs open
with SUSE to backport those fixes into current code, where applicable.

Usually the easiest way to reconcile this type of thing is to get the CVE
numbers of the applicable vulnerabilities from the auditor. If they
cannot provide those, fire them for incompetence. Once you have the CVE
numbers you can check SUSE’s vulnerabilities website, or the PHP package’s
changelog (rpm -q --changelog packageName) and see if the fixes are
present. Chances are good that they are since there are teams devoted to
maintaining these packages in this way for these very reasons.

There are regularly questions in the SLE forums on this topic; feel free
to review those for similar information and to help move toward the truth
of the situation.


Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

You can’t fix the issues because they haven’t told you what the issues are. Sounds blindingly obvious doesn’t it, and yet…

It might be interesting to see what the auditor’s report says if you remove version numbers from the HTTP headers. E.g.

HTTP/1.1 200 OK Date: Fri, 13 Jun 2014 15:48:48 GMT Server: Apache Content-Length: 745
Note lack of information about Apache. You can do that by setting

ServerSignature off ServerTokens Prod
In /etc/apache2/default-server.conf

You can also remove the ‘X-Powered-By: PHP/5.2.14’ from the HTTP headers. In /etc/php5/apache2/php.ini find the line

expose_php = On

change On to Off then restart apache.

Thanks. Ill give it a try.!!!

I will defanantly ask for the CVE file moday. I have still heard nothing from anyone today. So I will take the server off line until I get more information as what to fix.

Thanks
for all the info.

Thanks for your post. But I may have really goobered this up. I am using PHP 5.2.14 and the updates are for 5.3. Also I made a mistake the OS version is this
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PTCHLEVEL = 1

When I try to install any of the updates it returns with an error saying it cant find the required install of 5.3

When I try to install the 5.4.2 install, I get billions of dependency errors.

If it is not apparent, I am by far not an expert at Linux I worked in NetWare for 18 years, and the transition is tough.
What do I need to do to install 5.4. x.

Thanks
Dave.

SLES 11 SP1 is End of Life, unless you have purchased Long Term Service Pack Support. If you have Long Term Service Pack Support, just install all outstanding updates. If you don’t have Long Term Service Pack Support you should be concerned about more than just your PHP install. See https://www.novell.com/support/kb/doc.php?id=7012368 for how to update to SP3.

I wouldn’t bother with third party PHP packages unless it is explicitly explained to you what about your PHP installation is a security risk. If the SLE PHP packages are subject to some vulnerability, SUSE would probably be interested to know about that.

I am part of ALA software agreement and still have a year to go on it. But when I download the online updates the screen goes black and I have to revert back to the snapshot. Plus there are a lot of dependacy errors. I don’t know how to answer them, so I just chose the first option.

Have you attempted to update to SP3 yet or are you still trying to get SP1 up to date?

If you’re trying to apply updates to SP1, can you run

$ zypper clean -a

then post the output of $ zypper lr -u $ zypper up
Wrap the output in CODE tags (look for the # button on the toolbar when composing the post), otherwise it will be very difficult to read.
Otherwise, post exactly what commands you’re running and what the output is.

I would prefer to update to SP3. Would it be better to reinstall the server?

Whether it’s a better to re-install the server is something only you can decide really.

To update to SP3 you first need to bring your SP1 install up to date. That Knowledgeable article I linked says

So it’s a bit of a slog to get from SP1 to SP3. Re-installing from scratch with SP3 will probably be quicker, but you have to also consider the time it’ll take you to configure the server as you want it. Another factor is the state of your current installation. Given what you say happens when you try and install updates, it sounds like it might not be in a great state. If you’re not happy with the state of the current install and are confident you can configure the server as you want it after a clean install, probably best to start over with SP3.