I read this article recently on Ars: http://arstechnica.com/security/2014/03/php-bug-allowing-site-hijacking-still-menaces-internet-22-months-on/
I have some very old PHP servers still running some legacy code. They use PHP version 5.2.17
The article above states that PHP versions prior to 5.3.12 and 5.4.2 are vulnerable.
The fact that they mention 5.3.x and 5.4.x, it makes me think that 5.2.x is NOT vulnerable - is this correct?
Thank you to anyone who can confirm and provide a reputable source for this.
PHP versions prior to 5.3.12 and 5.4.2 are vulnerable.
5.2.17 is very much prior to both of those. If you look on http://www.php.net/ChangeLog-5.php#5.4.3, bug #61910 was fixed only in the 5.3 and 5.4 branch.
Having said that, the wording may be ambiguous. PHP 5.2 may be left out because it was not supported anymore. Or it may have been left out because the vulnerability only existed in 5.3+. I can't find definitive proof one way or the other.
Related
I have a simple question why do we need to upgrade PHP version on a live server? Is there any good reason to do so? I'm confused; we're using PHP 5.3 and our CEO doesn't want to update to PHP 5.5 which is recommended in Laravel 5. Can somebody give me reason why we should or we shouldn't do it?
Further to some of the comments on your question:
Do we need to upgrade PHP
The answer to this part of the question is "No". In some cases it might not be possible to upgrade as newer version can cause applications to break if they rely on older features.
Do we need to upgrade PHP for Laravel 5
The answer to this part is "Yes". You will have to upgrade for Laravel 5 as it relies on newer features of PHP that only exist from PHP 5.4 (Laravel 5) and 5.5.9 (Laravel 5.1).
Should we upgrade PHP
You didn't ask this question, but I put it in here because Yes, you should. Versions of PHP have a lifetime. They are supported in full for bugs for a while, and then they are supported for security flaws for slightly longer. However, after a while, versions of PHP will no longer receive any support. Security holes might be found in older version that will never be patched. You should keep your version of PHP up to date in order to remain safe from PHP vulnerabilities that may have been discovered.
As always, the PHP website contains all the information about the currently supported versions of PHP: http://php.net/supported-versions.php
In my case I'm trying to use the composer package "jeremykendall/password-validator" on a server that currently requires i use php 5.3.3-7+squeeze19.
But this lib requires php 5.3.7.
Any ideas of how I could get around this? or test if it works?
I'm thinking I could fork the lib to test, but does anyone know any composer features that could help here?
I'd suspect the reason for the requirements is the same as for ircmaxell's more famous password_compat library:
Requirements
This library requires PHP >= 5.3.7 OR a version that has the $2y
fix backported into it (such as RedHat provides). Note that Debian's
5.3.3 version is NOT supported.
The runtime checks have been removed due to this version issue. To see
if password_compat is available for your system, run the included
version-test.php. If it outputs "Pass", you can safely use the
library. If not, you cannot.
If you attempt to use password-compat on an unsupported version,
attempts to create or verify hashes will return false. You have been
warned!
The reason for this is that PHP prior to 5.3.7 contains a security
issue with its BCRYPT
implementation.
Therefore, it's highly recommended that you upgrade to a newer version
of PHP prior to using this layer.
It sounds like your 5.3.3 version does not have the backport fix (based on that it looks Debian based, confirm yourself if the fix has been backported specifically to your version or not), so you really shouldn't be running this code (or any bcrypt based code) on 5.3.3 as it may open you up to actual security vulnerabilities.
The library in question has a test suite. Simply run its tests on your 5.3.3 box and if they work you can be more confident in using it.
I would speculate that they might not: the author must have a good reason for specifying that particular version of PHP. There may be a bugfix in 5.3.7 that part of the library depends on.
In that case, I would suggest you write a couple of your own unit tests to ensure the parts of your code that use the library still work on that environment.
I was recently asked about a legacy application that is running on PHP 4.4.2 on IIS 6.0. We were informed that this version of PHP is out of date and contains security vulnerabilities
I personally, have zero experience with PHP.
It has been suggested that we upgrade PHP to a later version. According to Wikipedia, the latest stable version is 5.4. Is version 5.4 backward compatible with 4.4.2?
I assume that there is an installer for PHP 5.4 that we could run that would install the new version of PHP. Would that work safely and the legacy application would still run fine?
Are there any breaking changes in newer versions of PHP that might make upgrading the legacy PHP application risky?
Look at this, check for any deprecated code (especially preg VS ereg ) -
http://www.php.net/manual/en/migration5.incompatible.php
Look for the general differences -
http://www.php.net/manual/en/faq.general.php#faq.general.differences-45
Check about the migration -
http://www.php.net/manual/en/faq.migration5.php
EDIT -
One more general link, may be helpful at times -
Check Change Logs
I have updated the php version on our database so we can work some wordpress websites. since updating from PHP Version 5.2.1 to 5.2.17 we have had some issues with other services on our db.
So I'm woundering is PHP 5.2.17 backwards compatible with php 5.2.1?
Yes, it should be compatible. 5.2.1 and 5.2.17 imply the first and seventeenth patch release (still the 5.2.x release family), respectively. Check the changelog: http://us.php.net/ChangeLog-5.php
5.2.1-5.2.17 are mostly bug fixes and minor feature enhancements.
There are probably some subtle changes, so you will want to look through the summaries on that page of each release. Or at the very least search on the changelog page for the functions you are having problems with to see if there were any changes. Other than that, no, there shouldn't be any groundbreaking differences.
I'm starting to learn PHP. I would like to use PHP 5.3 because it's the newest version so far. I'm working on a project in which I'll use PHP 5.2 scripts that someone gave me.
Are they going to run just fine even though I'm using PHP 5.3?
PHP.net features a guide for upgrading from PHP 5.2.x to PHP 5.3. This includes a section on backwards compatibility.
From my experience, the transition from 5.2 to 5.3 went pretty smoothly smoothly. The only problems I had with my app was to ensure my DateTime setting were property configured in my php.ini, and filter out some overly-agressive deprecation warnings that started showing up.
No, 5.3 is not backward compatible, and by all means it shouldn't be seen as a minor version upgrade.
There is a page dedicated to incompatible changes: http://www.php.net/manual/en/migration53.incompatible.php
Also consider functions you have designed but have been accepted into 5.3. Since php doesn't support overloading or overwriting of functions, this will give an error.
For the most part, minor version releases aren't going to cause you problems. You should be okay.
Obviously, if you do have any problems, you'll want to make sure you have error_reporting set to see all errors. PHP: error_reporting
Also, check the manual for changes in 5.3 from 5.2: Migrating from PHP 5.2.x to PHP 5.3.x
There are some minor issues. Call time pass by reference are deprecated. There are new reserved words (ie. goto).
php has no backward compatibility in all version. It often removed some functions when it changed version. The problem occurs when you have to upgrade server and need to change php version but some php scripts no longer work with new php version. You also have to correct php script which is a bigger job. But if the script belong to other users rather than yours, you can't upgrade those scripts. This is a real headache situation that I'm fed up with php and switch to perl instead for backward compatibility reason.