But as dependant these businesses are on PHP, they constantly resist adoption of newer versions. They see adoption and change as a risk to losing their market share and end-user trust. It is a struggle leading to a history making security threat to today's web.
It Starts with Awareness
Many talk about writing secure PHP code. But not much information is written about why upgrading PHP versions makes web applications more secure. The first step is to be aware of the security vunerabilities. There are many websites and other resources for CVE, Common Vulnerabilities and Exposures. But my favorite is the CVE details database.
Threat Types
- DoS - In a denial-of-service DoS attack, an attacker attempts to prevent legitimate users from accessing information or services. By targeting a computer and its network connection or other services that rely on the affected computer. Sometimes the attacker can inject and execute arbitrary code while performing a DoS attack in order to access critical information or execute commands on the server.
- Code Execution - an attacker's ability to execute any commands of the attacker's choice on a target machine or in a target process. It is the most powerful effect a bug can have because it allows an attacker to completely take over the vulnerable process. From there the attacker can potentially take complete control over the machine the process is running on.
- Overflow - more commonly known as stack overflows occur when variable size data is copied into fixed length buffers located on the program stack without any bounds checking. Vulnerabilities of this class are generally considered to be of high severity since their exploitation would mostly permit arbitrary code execution or Denial of Service. Rarely found in interpreted platforms, code written in C and similar languages is often ridden with instances of this vulnerability.
- Memory Corruption - Using memory beyond the memory that was allocated buffer overflow. If an array is used in a loop, with incorrect terminating condition, memory beyond the array bounds may be accidentally manipulated. Buffer overflow is one of the most common programming flaws exploited by computer viruses.
- Sql Injection - SQL Injection is one of the many web attack mechanisms used by hackers to steal data from organizations. It is perhaps one of the most common application layer attack techniques used today. It is the type of attack that takes advantage of improper coding of your web applications that allows hacker to inject SQL commands into say a login form to allow them to gain access to the data held within your database.
- XSS - Cross-site Scripting (XSS) refers to client-side code injection attack wherein an attacker can execute malicious scripts (also commonly referred to as a malicious payload) into a legitimate website or web application. XSS is amongst the most rampant of web application vulnerabilities and occurs when a web application makes use of unvalidated or unencoded user input within the output it generates.
- Directory Traversal - Properly controlling access to web content is crucial for running a secure web server. Directory traversal is an HTTP exploit which allows attackers to access restricted directories and execute commands outside of the web server’s root directory.
- Http Response Splitting - HTTP response splitting occurs when data enters a web application through an untrusted source, most frequently an HTTP request. The data is included in an HTTP response header sent to a web user without being validated for malicious characters.
- Bypass something - bypass vulnerabilities of authentication, web server limitations or operating system limits are generally caused by programmers assuming that users will behave in a certain way and failing to foresee the consequences of users doing the unexpected.
- Gain Information - Intruders may be able to gain access to specific information stored on the host, including security settings. This could result in potential misuse of the host by intruders.
- Gain Privileges - Privilege escalation is the act of exploiting a bug, design flaw or configuration oversight in an operating system or software application to gain elevated access to resources that are normally protected from an application or user. The result is that an application with more privileges than intended by the application developer or system administrator can perform unauthorized actions.
- CSRF - Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf) or XSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts.
- File Inclusion - File inclusion vulnerability is a type of vulnerability most often found on websites. It allows an attacker to include a file, usually through a script on the web server.
Multiple Exploitation Fronts
Being aware of the types of threat is not enough. What many don't realize is a security threat can take on place on multiple fronts. They can be independent or interdependent.
This is one of the facts that many open source projects miss. They assume that once a piece of code is patched then the security problem has been removed forever. Not recognizing that it still remains but only has been obstructed by a re-factoring of a singularly obvious instance. A threat can re-occur over time through code base changes. In a project with thousands of contributors both core and third-party. The chances of the same exploit being written into the code base several times over is extremely high.
- Web Server - A web server is an information technology that processes requests via HTTP, the basic network protocol used to distribute information on the World Wide Web. The term can refer either to the entire computer system, an appliance, or specifically to the software that accepts and supervises the HTTP requests.
- Server Operating System - The operating system is the most important program that runs on a computer. Every general-purpose computer must have an operating system to run other programs and applications. Operating systems perform basic tasks, such as recognizing input from the keyboard, sending output to the display screen, keeping track of files and directories on the disk, and controlling peripheral devices such as disk drives and printers.
- Code run-time execution - A runtime program is an application that is distributed for use. Code runtime environments can be one of several interpreters, compilers and virtual machines being the most common.
- PHP interpreter
Web Server Vulnerabilities
You can find hundreds of tutorials and best practices for securing PHP on the web server. You'll also find that the popular web servers like Apache are in a constant state of flux and newer versions being readily adopted.
There are five vulnerabilities fixed in the latest release of the Apache Web server, including a buffer overflow and several denial-of-service vulnerabilities. Fixes for these flaws have landed in the developer release of the serverThis trust in new versions is something that the PHP interpreter does not enjoy.
There
are five vulnerabilities fixed in the latest release of the Apache Web
server, including a buffer overflow and several denial-of-service
vulnerabilities. Fixes for these flaws have landed in the developer
release of the server, 2.4.10-dev. - See more at:
https://threatpost.com/five-vulnerabilities-fixed-in-apache-web-server/107278/#sthash.nisaKBbV.dpuf
Code Vulnerabilities
The big three CMS are constantly pushing for users to upgrade to close security holes allowed in code. They create message applications designed for upgrading extensions. They have mailing lists with subscribers numbering in the thousands. All dedicated to maintaining security within this area.PHP Interpreter Vulnerabilities
This is the area where information is weak. Where upgrading PHP can increase security by removing an exploitation front. decreasing threat levels in others. Because in the first categories there are hundreds of developers and bloggers pointing fingers at the other items. Yet they never mention upgrading the PHP version that also might be responsible for making the exploit possible. One might suppose they either assume version upgrades or don't care.Honestly, I think that the largest failure in this area is hubris. Developers and DevOps can show-off their intelligence with knowledge of code and server security. But they are well aware of the fact that version upgrades can break many things and make them look bad.Even in the face of a warning upgrading PHP will be delayed and hopefully the responsibility can be handed off to the web hosting company. The hosting company on the other side is of course waiting for a catastrophe or land slide of complaints before acting. The resulting stalemate of inaction is what hackers count on for access.
A newly reported critical vulnerability in PHP enables would-be cyber criminals to steal source code or inject and run malware in PHP applications by adding command-line parameters to URLs. Fortunately, The PHP Group has announced updates to PHP that its says eliminates the vulnerability. -- infoworldThe hosting company might make a newer version of PHP available but they will not enforce it's use. In the mean time script kiddie bots are searching for sites to exploit.
The state of PHP Security
Note that the year of 2007 was very high in vulnerabilities and also was the slowest adoption rate of a new version of PHP. One only has to extrapolate to see that the increase in threats was due to less secure versions remaining available for an overly long period.When you don't take in account the upgrading of PHP into your security efforts then you are pouring them into a leaky bucket. It's is only a matter of time before a widespread threat event. Imagine if your code is a major player in supporting the 30% or so of websites that use a CMS.
3 |
4 |
13 |
11 |
6 |
17 |
33 |
114 |
20 |
22 |
35 |
35 |
22 |
13 |
32 |
26 |
2000 3 2001 4 2002 13 2003 11 2004 6 2005 17 2006 33 2007 114 2008 20 2009 22 2010 35 2011 35 2012 22 2013 13 2014 32 2015 26 |
| 110 |
64 |
130 |
105 |
12 |
9 |
7 |
3 |
36 |
16 |
3 |
2 |
Execute Code 110 Bypass Something 64 Denial of Service 130 Overflow 105 XSS 12 Directory Traversal 9 Sql Injection 7 Http Response Splitting 3 Gain Information 36 Memory Corruption 16 Gain Privilege 3 File Inclusion 2 |
PHP for Business sake
Zend really does not push hard enough in the business sector. Whitepapers that hide behind registration. The top three CMS also tend to ignore the threats imposed by not setting the minimal version of PHP high enough.
Companies and individuals that make PHP part of their business plan are not including security updates and changes to PHP in that plan. When they quite obviously should but instead waitng until the tide of change is upon them and it becomes a choice between swimming or dying.
Even as WordPress Core continues to expand its support for new versions of PHP, we have no intention of abandoning support for older versions until usage numbers show that the impact on users will be minimal. -- Aaron JorbinThey are more influenced by benchmarks by version upgrade. Benchmarks that might lead to a greater market share. In no blog or press release will you ever find any mention of setting a minimal PHP version due to security concerns.
The leadership of open source PHP projects are ignorant of PHP version security and pass this ignorance on to their users.
Many websites use a content management system, a forum or a blog tool and these systems work with both PHP4 and PHP5. And for a long time, they've worked better with PHP4 than with PHP5. I can only talk about Drupal, but from what I've seen, very few Drupal users show incentive to upgrade from PHP4 to PHP5. They are pretty much ignorant to what version of PHP they use, as long Drupal works well.You might again notice that there is no mention of the security differences between PHP4 and PHP5. As the move to PHP7 begins there is more concern with performance leaving any potential security improvements behind. I conversations between community members about PHP version usage the topic of security never appears to be of concern. Not even worth mentioning in a proposal to message users during installation.
-- Dries Buytaert
"Your PHP installation of %current_version is receiving official security support until %date. Upgrading to %version is recommended to take advantage of bugfixes etc."Pushing aside the hard work of getting it right in favor of doing nothing.
Shared Hosting Tragedies
Because shared hosting is the most popular source for delivery of PHP web applications. They usually complete the Gordian knot of because they do not want to deal with the problems involved when things go wrong. This can cost them thousands of hours in support while trying to smooth over a list like this one. It was long enough ago that these projects had problems in transitioning form one PHP version to the next. You'd think they might be more prepared or at the very least expect that it could happen again.
- Magento Community Editions 1.6.x, 1.7.x and 1.8.x require the “PHP5.4 support patch” which can be downloaded here (scroll to bottom of page): www.magentocommerce.com/download
- Zen Cart versions 1.5.0 and 1.5.1 require patches to work with PHP5.4. Older versions 1.3.8 and 1.3.9 will not run on PHP5.4. The next version 1.5.2 will run natively with 5.4 but as this currently in beta, we do not recommend to use it yet for live production sites.
- openCart does not provide any official information on PHP5.4 compatibility, but versions 1.5.4.x or higher should all work well. The current OC version is 1.5.6.1, for details and downloads see www.opencart.com/index.php?route=download/download
- PrestaShop has no definitive advice on PHP5.4 compatibility but the PS forum users have reported no issues in running PrestaShop version 1.5.0 or higher. As PS 1.4.x is no longer under active development, we’d recommend an upgrade to 1.5.x in any case to keep your site secure. To download the current 1.5.6 version go to www.prestashop.com/en/download.
- osCommerce is compatible with PHP5.4 since version 2.3.3.0 or higher www.oscommerce.com/Products http://library.oscommerce.com/Online&en&oscom_2_3&release_notes&v2_3_3.
- WordPress versions appear to run well on PHP 5.3 and 5.4. The main problems with WordPress can be plugins – if you encounter a blank screen (fatal PHP error) or error messages, see the trouble shooting tips below. To download the current 3.8.1 version go to wordpress.org/download/.
- Joomla versions 1.6.x, 1.7.x, 2.5.x and 3.x all run on PHP5.4, for details see www.joomla.org/technical-requirements.html. The older Joomla 1.5.x has serious security flaws, making it a prime target for exploits by hackers. Anyone running Joomla 1.5.x versions is strongly recommended to upgrade as soon as possible.
- Drupal version 7 should run well on PHp5.4 but the older version 6 is unlikely to work on 5.4 mainly due to incompatible plugins. For more information on PHP compatibility see drupal.org/requirements/php and to download the current 7.26 version go to drupal.org/download.
- CMS Made Simple versions 1.7 “Cape Verde” or higher should all run well on PHP5.4. Improvements in PHP error reporting were made in version 1.9 “Bora Bora” which are recommended. Current version is CMS 1.11.10 “Pinzon” which can be downloaded here: www.cmsmadesimple.org/downloads/
Most just continue offering older PHP 5.2 5.3 versions without looking at the vulnerabilities. Security support operatives are conspicuously missing.
Just use our PHP Switcher to choose PHP 7, or choose between 5.2, 5.3, 5.4, 5.5 or 5.6 as well. -- A2 Hosting
The Usual Suspects
You should really read the database but here I will highlight some of the most obvious security threats made possible by not upgrading to the latest version.
Here is a short list of threats in the top categories. These are helpers to poor code security.
SQL Injection
- sapi/cgi/cgi_main.c in PHP before 5.3.13 and 5.4.x before 5.4.3, when configured as a CGI script (aka php-cgi), does not properly handle query strings that contain a %3D sequence but no = (equals sign) character, which allows remote attackers to execute arbitrary code by placing command-line options in the query string, related to lack of skipping a certain php_getopt for the 'd' case. NOTE: this vulnerability exists because of an incomplete fix for CVE-2012-1823.
- PHP before 5.3.10 does not properly perform a temporary change to the magic_quotes_gpc directive during the importing of environment variables, which makes it easier for remote attackers to conduct SQL injection attacks via a crafted request, related to main/php_variables.c, sapi/cgi/cgi_main.c, and sapi/fpm/fpm/fpm_main.c.
XSS
- The utf8_decode function in PHP before 5.3.4 does not properly handle non-shortest form UTF-8 encoding and ill-formed subsequences in UTF-8 data, which makes it easier for remote attackers to bypass cross-site scripting (XSS) and SQL injection protection mechanisms via a crafted string.
DOS
- The PDORow implementation in PHP before 5.3.9 does not properly interact with the session feature, which allows remote attackers to cause a denial of service (application crash) via a crafted application that uses a PDO driver for a fetch and then calls the session_start function, as demonstrated by a crash of the Apache HTTP Server.
Dangers of Fence Riding
There are hundreds of reasons to upgrade to PHP7. But what is needed for open source projects recognition of the dangers of supporting multiple PHP versions. Where they strongly recommend rather than draw a hard line on minimal version. 
Implement it as a security feature not as a burden. I list here the vulnerabilities that might occur in everyday use of PHP or one might find in a CMS or Framework. Stop collaborating with projects that do not support this effort. Applaud the efforts of those that do. A poll of Symfony users shows that rather than be bold and forage ahead they would rather continue to ride the fence until something awful happens.
| Version | Votes | % |
|---|---|---|
| 5.3.3 | 31 | 2% |
| 5.3.x | 56 | 3% |
| 5.4.x | 260 | 16% |
| 5.5.x | 568 | 35% |
| 5.6.x | 495 | 30% |
| 7.x | 225 | 14% |
The fact that more than three hundred votes were cast for end of life PHP versions means that awareness levels are terribly low. It also does not help that the roadmap is outdated. Projects need to be more pro-active in the PHP movement rather than just use what's thrown at them by the circumstances of hosting companies.
Based on these results, I propose to make PHP 5.5 the minimum PHP version required for Symfony 3.0. I want to keep the possibility to bump to PHP 5.6 sometime next year based on our needs and on the most popular PHP versions used by hosting companies and Linux distributions.
This coupled with the efforts to acquires 100% PHP7 compatibility sends mixed signals to developers. At very least down plays the importance of upgrading PHP versions between major changes.
Lastly, we've just removed php: nightly from the list of PHP engines which
can silently fail. This means that Symfony no longer accepts changes that break
PHP7 compatibility, not even in the master branch where the upcoming Symfony 3
is being developed. -- Symfony
Refactor and update code to a minimal version and create a true quality assurance standard. A standard that all can adhere to and one form which the entire web can benefit.(Yeah, FIG I am tallking to you here's another good standard that can be put in your crappy PSR's) Make choices that might cost a bit of reputation over those that only allows security threats to live on.
- PHP before 5.4.41, 5.5.x before 5.5.25, and 5.6.x before 5.6.9 truncates
a pathname upon encountering a \x00 character in certain situations,
which allows remote attackers to bypass intended extension restrictions
and access files or directories with unexpected names via a crafted
argument to (1) set_include_path, (2) tempnam, (3) rmdir, or (4)
readlink. NOTE: this vulnerability exists because of an incomplete fix
for CVE-2006-7243.
- The phar_parse_tarfile function in ext/phar/tar.c in PHP before 5.4.41, 5.5.x before 5.5.25, and 5.6.x before 5.6.9 does not verify that the first character of a filename is different from the \0 character, which allows remote attackers to cause a denial of service (integer underflow and memory corruption) via a crafted entry in a tar archive.
- ext/phar/phar.c in PHP before 5.4.40, 5.5.x before 5.5.24, and 5.6.x before 5.6.8 allows remote attackers to obtain sensitive information from process memory or cause a denial of service (buffer over-read and application crash) via a crafted length value in conjunction with crafted serialized data in a phar archive, related to the phar_parse_metadata and phar_parse_pharfile functions.
Food for thought
Sometimes a raw list is not effective or convincing enough to consider. You still might be thinking. "But I don't use those so I don't need to upgrade" .
Here's some other reading about how to actually exploit that might get you thinking. It uses one of the more common PHP functions. One that even an extreme newbie might come across.
As you can see the file is successfully included (it works with every single filesystem function of PHP that makes use of _php_stream_fopen() and similar functions).
Take note of the PHP versions used here. Wait! your saying, surely PHP 5.4 is okay for now? Hmm, not really which version are using?
“You’d think these bugs would be long forgotten, but it isn’t so; they’re like the undead. Vulnerabilities never die,” Shteiman said. “They don’t die and we realize if we see this executed by botnets trying to onboard servers and by crimeware kits being sold, that means attackers understand they can rely on old problems because people won’t fix them and attackers don’t have to work too hard.” -- Barry Shteiman
So it looks like even experts like Shteiman are guilty of not towing the line for evangelising upgrading of the PHP interpreter. Taking preference in speaking out to code writers rather than server environment maintainers.
“PHP
is installed as an interpreter,” Shteiman said. “Replacing the existing
instance of PHP with a new one means downtime. Sometimes you may have
to change applications because some things that are now deprecated may
require application changes. For that reason, sometimes organizations
don’t patch or go a different route. They might use a new framework
instead.” - See more at:
https://threatpost.com/new-exploits-arrive-for-old-php-vulnerability/104881/#sthash.7yneHGpv.dpuf
“PHP is installed as an interpreter,” Shteiman said. “Replacing the existing instance of PHP with a new one means downtime. Sometimes you may have to change applications because some things that are now deprecated may require application changes. For that reason, sometimes organizations don’t patch or go a different route. They might use a new framework instead.” -- Barry Shteiman
Update:
This reminder of large vendor interference of adoption of the latest versions of PHP comes from Remi Collet.
Notice that Enterprise distributions usually backport security fixes into their stable packages, e.g. for RHEL -- Remi ColletThe automated update systems used by RedHat have always been a problem because while they are trying to help. They really are facilitating slower adoption for customers that are shared hosting providers who will in turn provide old releases to their clients.
We use the term backporting to describe the action of taking a fix for a security flaw out of the most recent version of an upstream software package and applying that fix to an older version of the package we distribute.This pollutes the PHP ecosystem with version confusion as the trust in upgrading via the version number process is broken and lost. I even hesitate to disseminate this information as I see it as being more harmful than helpful to the PHP ecosystem. Do us all a favour RedHat, don't do us any favours.
Backporting is common among vendors like Red Hat and is essential to ensuring we can deploy automated updates to customers with minimal risk. Backporting might be a new concept for those more familiar with proprietary software updates.
Backporting has a number of advantages for customers, but it can create confusion when it is not understood. Customers need to be aware that just looking at the version number of a package will not tell them if they are vulnerable or not. For example, stories in the press may include phrases such as "upgrade to Apache httpd 2.0.43 to fix the issue," which only takes into account the upstream version number. -- RedHat
Comments
Post a Comment