Page 2 of 3

Re: Raising The Bar On Security

Posted: Mon May 19, 2014 1:48 pm
by zjoomla22
Yes I am excited! This is causing many issues!
I have a web developer client that clicked the update button and 11 websites, they all updated to version 3.3 and they are all are now down.
How does one explain that to the owners of the websites?

I use 1and1 servers loaded with Plesk 11.5 - they have been the best company for servers I have ever used and worked with.
They have great people in support and they are very security aware. It was a new server installed form scratch.

Now need to get back to finding a solution for getting these site back up.

Re: Raising The Bar On Security

Posted: Tue May 20, 2014 1:49 pm
by mandville
zjoomla22 - i assume you restored from a back up and checked the requirements before upgrading ?

Re: Raising The Bar On Security

Posted: Tue May 20, 2014 1:56 pm
by nickbunyan
mandville wrote:zjoomla22 - i assume you restored from a back up and checked the requirements before upgrading ?
Hi @mandville - I guess you meant they should take a backup rather than restore a backup. He/she could also have tried testing on a non-critical site or, dare I say it, RTFM...?

Re: Raising The Bar On Security

Posted: Tue May 20, 2014 2:15 pm
by mandville
i understood that the normal process is to restore a known good back up (you do take them dont you?), eg pre the disaster caused by joomla improving its security measures.
You might be best to clarify with your "web developer client" what they have the power to do and whose fault it actually is.
we all (should) know about 1&1 security skills

i wasnt sure the was any M in RTFM especially pages like this ... #Upgrading

Re: Raising The Bar On Security

Posted: Tue May 20, 2014 2:30 pm
by nickbunyan
@mandville. Sorry - miscommunication on my part re your advice to zjoomla. You appeared to be suggesting he restore a backup before upgrading when it seems clear you intended to suggest he should have 'taken' a backup before upgrading in order to be able to 'restore' after if it went wrong...

Personally, I tend to incline to the 'If you screw up, you carry the can' philosophy as far as 'web developer clients' go. And you are right about the 'M' I was just being lazy and using RTFM as a generic term ;-)

As I said originally - with my hosting service Joomla refuses to 'upgrade' because the PHP check fails but YMMV.

Re: Raising The Bar On Security

Posted: Fri May 23, 2014 9:06 am
by ErikLtz
Well, I'm too running CentOS 6.5 with the standard php 5.3.3 that INCLUDE the 5.3.10 security fixes... trying to install anyway... changed 5.3.10 to 5.3.1 in three places in the Joomla source - now an error is logged instead...

Error for missing method DirectoryIterator::getExtension apparently added in 5.3.6... modified libraries/joomla/database/ driver.php to use simple substr on filename ending instead (quick and dirty)... the pre install check worked...

But ran into error with missing INSTL_LANGUAGE_LABEL when changing language - apparently in libraries/joomla/filter/input.php from using the encoding parameter for get_html_translation_table added in 5.3.4: ... -table.php

So, fixed and install could finish :)

Can view the site (empty Joomla 3.3 running on PHP 5.3.3 in CentOS 6.5). Two more 5.3.10 changed to 5.3.1 under /administrator and I could login there too.

This is of course NOT recommended and NOT AT ALL fully tested - just "proof of concept" that Joomla 3.3 can be installed on CentOS 6.5 running the stock PHP 5.3.3. Having CentOS officially update the PHP version to something newer would be best, but that will probably not happen until CentOS 6.6 (?!). Additionally it appears that there are some code lines (and I haven't tested more than install and login) that not only "raise the bar" for security reasons but also use new methods and parameters added in later PHP versions.

Being such a widely used CMS as Joomla, making decisions to rule out a majority of the stable OS platforms this way - platforms where security fixes ARE retrofitted into the supported PHP version - is *not nice* and will hurt the Joomla CMS :-|

I'd vote for a Joomla 3.3.1 release where the version checks are relaxed to allow 5.3.3 (with a warning or something) and avoid using >5.3.3 methods and parameters.

Re: Raising The Bar On Security

Posted: Fri May 23, 2014 3:58 pm
by zjoomla22
I totally agree ErikLtz! I am now thinking that Joomla is focused on Windows hosting. The use of Joomla on Linux servers does not appear to be a supported and stable thing to do. Somehow the upgrade was allowed to proceed on unsupported linux systems, taking the site down. Really not sure if security was the main point.

Re: Raising The Bar On Security

Posted: Mon Jun 02, 2014 6:38 pm
by Greg_E
Coming back to see if anything had been done, and I do like the warning only and maybe a check box that makes the user agree that security breaches due to "old" PHP might be possible is probably a better way at this moment. Maybe a disclaimer under the warning that if you are running CentOS, Debian, Redhat, etc that you are probably OK and the error is a result of a versioning difference. And in time maybe a reliable way of detecting these back ported patches will be build into the operating systems.

Re: Raising The Bar On Security

Posted: Mon Jun 02, 2014 8:48 pm
by ErikLtz
Yes Greg_E and zjoomla22, agree - but even more worrying is the lack of response from the Joomla team regarding a *serious issue*.

We are writing in the "official raise the bar on security" comment thread, but still no new response from mbabker et al regarding running J3.3 on the large supported distros :-(

Re: Raising The Bar On Security

Posted: Mon Jun 30, 2014 10:46 pm
by JustBear
I am wondering what everyone is doing about this issue? I have held back upgrades as I am also concerned about using different repos for PHP on CentOS.

Re: Raising The Bar On Security

Posted: Mon Jul 07, 2014 6:59 pm
by murdoka1
It looks like CentOS now has a release candidate available of the new version 7, which comes with PHP 5.4.16. This would accommodate the latest Joomla requirements for the minimum PHP version.

Re: Raising The Bar On Security

Posted: Sun Jul 13, 2014 1:27 am
by Greg_E
CentOS now has version 7 on release, but it is going to take some time to get all the packages up to 7. And it still doesn't take away from CentOS 6.x being supported until the year 2020. I would still like to see the burden of security checks placed on the server operator so that they can decide if they are patched or that they don't care or that they are going to install a different distro or if they are going to move up to the next full version of their operating system.

I'm struggling with this choice right now because I may need to teach a beginner's course in Joomla and I'm trying to decide if I make "live" disks for CentOS 6.5 that I'm somewhat familiar with using and is a mature and stable OS, or if I will go up to CentOS 7 that is less than a week old (at time of this post) and hope everything is good and that everything I need is available. The repos for CentOS 7 are not fully updated yet, not sure if Flash has been updated yet, and Gnome3 is certainly a little bit slower on the couple of machines that I've checked. (these will be learning machines, a GUI comes in real handy once in a while)

I'd like to be able to use Joomla 3.5LTS which should come out before this course would happen, I certainly don't want to step back to Joomla 2.5 or leave people stuck at version 3.2.4 just to make sure it works on my stable CentOS 6.5.

To me a simple check and page that comes up and says "Your PHP version has been found to be less than 5.3.10, are you sure you want to install on a possibly non-secure version?" A "yes" proceeds to install and a "no" stops everything so you can check for yourself.

Probably beating a dead horse at this point

Re: Raising The Bar On Security

Posted: Sat Jul 19, 2014 11:52 pm
by RedEye
murdoka1 wrote:It looks like CentOS now has a release candidate available of the new version 7, which comes with PHP 5.4.16. This would accommodate the latest Joomla requirements for the minimum PHP version.
Really, they ship 5.4.x with the new release, instead of 5.5.x? Compiling your own version seems to be the best idea with CentOS here^^

Re: Raising The Bar On Security

Posted: Thu Jul 24, 2014 8:38 pm
by emodular
The PHP requirement is extremely frustrating.

Like JustBear, I'm also wondering what approach others (with CentOS 6.5 for example) have taken. Are you staying at 3.2.4 for now? Or, are you manually updating php with a third party repository?

Any advice would be greatly appreciated.

Re: Raising The Bar On Security

Posted: Thu Jul 24, 2014 9:12 pm
by termino
I think you should check this thread

Re: Raising The Bar On Security

Posted: Tue Aug 05, 2014 5:51 pm
by esptjoomla
Holy Cow...The security argument is important, but the fact that Joomla Team has not engaged with the major paid distros to make an easy upgrade path possible is a painful for of suicide. All my systems are RHEL/Centos and as it appears in this thread so are many others. How does the Joomla Team think this will play out???? I am feeling bent over!

Re: Raising The Bar On Security

Posted: Wed Aug 06, 2014 2:46 pm
by shodanshok
Hi all,
with CentOS 6.5 it is possible to use the CentOS Software Collections to have a side-loaded PHP 5.4 installation. The good thing is that SCL is a official CentOS/Red Hat repo, albeit the package it hosts are newer than "base" repo.

You need to do the following:
- install SCL repo and PHP 5.4
- setup a PHP wrapper script (via CGI)
- configure your virtualhost

1) Install SCL repo:

Code: Select all

 yum install -y centos-release-SCL.x86_64 

Code: Select all

 yum install -y php54.x86_64 php54-php-mysqlnd 
2) Setup the PHP wrapper script
change directory to /var/www/cgi-bin and inside it a file called php54-wrapper with the following content

Code: Select all

source /opt/rh/php54/enable
exec php-cgi
Then give it execution permission and secure it:

Code: Select all

restorecon -RF /var/www/cgi-bin/php54-wrapper
chown apache:apache /var/www/cgi-bin/php54-wrapper
chmod ugo-rwx /var/www/cgi-bin/php54-wrapper
chmod ug+rx /var/www/cgi-bin/php54-wrapper
3) Configure your virtualhost
For the VirtualHost that you want to configure to use PHP 5.4, add the following line in the .conf file:

Code: Select all

AddHandler php-cgi .php
Action php-cgi /cgi-bin/php54-wrapper

<Location />
    Options +ExecCGI
At this point, you virtualhost will use the new PHP 5.4 version via CGI (mod_cgi).
If you want better page load performance, you can use the fastCGI module or mod_fcgid (you can find much documentation on the net; anyway, the basic concept is the same).

Happy coding ;)

Re: Raising The Bar On Security

Posted: Fri Aug 15, 2014 9:34 am
by rutin

Re: Raising The Bar On Security

Posted: Wed Aug 27, 2014 2:56 pm
by ruijorgesilva1
From Portugal, with sadness :(
After reading all posts, i must consider this (my opinion):

Was having an Elastix server with joomla. Lots of bugs, allways upgrading things - php including. Allways an Headache with those problems.
Jumped to CENTOS. Stable, secure. Took me months of studing, learning, building everything. And now that i'm breathing of relief, it comes THIS!

Joomla producers:

Let me thank you so much for building this for free - telling you sincerely ;). I've never had an easy and wonderfull platform for an website.

But let me say this:
You don't want bad press! But you are having it! Right now! Everyone is talking about this! It's global!

You could whashed your hands - like pilates - and let people choose.
"We don't take any responsanbilities for you not having php 5.3.10" etc. Terms & Conditions?
You should put responsability on website builders and servers administrators. It's on their own.

Thinking not only, in other people, but me!
Another CENTOS??? Another building?? Another install?? And then?
You wake up in the morning and decide to change to another php version? And we? Are we swimming in the pool? Are we taking sun baths?

Shouldn't you consider changing the joomla 3.3 version, to accept php 5.3.3 with the risk of others accepting the security breaches?

I'm waiting for the Portuguese package to be available, but it will be deployed only on the 3.5 Version. But we still are going on 3.3.

Am I wrong or should already version 3.5 would be available»? I'm not certain about this information! I'm still working on english due to this "delay".

So, please, if you are spending time reading this, let me thank you for your time. And concluding:

Make people happy, even if they are running on security risk. If they accept, ti will be on their responsability. Let them choose.

Don't choose for them. Freedom. Just that. Freedom

Re: Raising The Bar On Security

Posted: Wed Aug 27, 2014 3:11 pm
by mandville
Did the bad press include this link ... urity.html

Re: Raising The Bar On Security

Posted: Fri Sep 12, 2014 8:31 pm
by mbabker
As stated previously, for technical reasons it was not possible for us to make the changes discussed in the blog post and reliably support older PHP versions. This was attempted in 3.2.0 and was a failure.

Re: Raising The Bar On Security

Posted: Sat Sep 13, 2014 4:11 am
by RedEye
It's funny in my eyes that the CentOS users are crying here, go on and blame CentOS for using so damn old versions for their packages!
murdoka1 wrote:It looks like CentOS now has a release candidate available of the new version 7, which comes with PHP 5.4.16.
Version 7 released July 2014 and the php package is build on a version what was released on 06-Jun-2013

CentOS 6.5 was released on 2013-12-01 and the php package (5.3.3) is build on a version what was released on 22-Jul-2010...

Seems that they don't really care about the php package they ship.

Re: Raising The Bar On Security

Posted: Mon Sep 29, 2014 9:57 am
by svictor
I’m building a website for a research team of the French National Research Center (CNRS). It will be hosted on the CNRS web hosting service which has PHP 5.3.3 It is difficult to tell when they will upgrade to a newer version. It will take a few months before my site goes online anyway, so maybe things will have moved meanwhile.

Am I safe in starting with Joomla 3.2.5 and expecting a smooth transition to the 3.3 branch later if the CNRS moves to PHP 5.3.10? I’m also worried that they might only upgrade to less than 5.3.9. In that case, my site will have to stay in the 3.2 branch. As I understand the announcement, the latter will be completely unmaintained starting with october this year?

I have very little leverage on the CNRS hosting service, so I have to make the right choices beforehand… I’d welcome any advice on that!

Re: Raising The Bar On Security

Posted: Thu Oct 23, 2014 7:16 am
by rosemarry
I have a number of client sites hosted by a company who are very professional and offer me a very good business model.

Sadly some of my clients are now telling me I need to upgrade them to Joomla 3.3 - and I have to tell them I can't - because in common with many other Hosters they are running Centos/Plesk, fully patched, but as far as Joomla is concerned "at the wrong level". The security of the environment and installation is obviously important, but refusing to install and forcing the Joomla user to consider alternate setups is clearly not the way to go.

Re: Raising The Bar On Security

Posted: Mon Dec 22, 2014 5:46 pm
by jeffatrackaid
I am a bit late to this but requiring an arbitrary version of PHP in the name of security is laughable.

The security issues in Joomla are rarely, if ever, due to the version of PHP.

PHP itself is very secure. Programmers make it insecure.

By turning the discussion to PHP versions, you detract from the core issue:

Joomla developers (particularly extensions) need to focus more on security.

If you review, where do you see ....

"This is due to an issue in PHP and not a Joomla security issue."

The fact is you don't.

You've not made Joomla more secure -- you've simply made it more difficult to use.

Re: Raising The Bar On Security

Posted: Mon Dec 22, 2014 11:37 pm
by brian
Sadly you misunderstand - in order for Joomla to offer greater security such as using bcrypt for password hashing the only option is to require a version of php that has not been dead for 4 years

Re: Raising The Bar On Security

Posted: Thu Jan 29, 2015 6:04 pm
by steve-cousins
It seems that the issue has gone around and around quite a bit and it appears that some people think that Redhat/CentOS/Scientific Linux is not up-to-date because of the version number that they use. My understanding is that they use 5.3.3-* for their version 6 (for instance CentOS 6) release of php is that that was the version number when the distribution was first released. The number in place of the * is their particular release number (backport) since then. It isn't that the security features that Joomla wants in place are not in the php versions that these distributions provide.

It sounds like it was attempted to test for backported versions and it "failed massively". So why test for a version at all? I suggest doing things one of two ways: 1. isolate which features you want and test php for those features, or 2. don't test at all and let people install it in whatever way they can or want, and let them deal with security issues rather than imposing some arbitrary limit.

It "sounds" good to say that this policy is being done for the greater good but it is evident that it wasn't thought out well if it is excluding major distributions like Redhat and Debian. I use CentOS 6 on many systems and have been asked to put Joomla on one of them for a national organization. I would think that Joomla would do whatever it could to promote use like this.

Has anything happened lately to fix this situation?



Re: Raising The Bar On Security

Posted: Thu Jan 29, 2015 9:30 pm
by mbabker
There has been no change in status, and I don't foresee a change coming anytime soon, especially now that PHP 5.3 itself has reached end of support. Even if we were able to test PHP for the proper BCrypt hashing mechanism with 100% accuracy, we would only be able to get back down to PHP 5.3.7 as the minimum supported version due to reliance on a third party library which backports the PHP 5.5 password hashing API (this version was chosen because of the security flawed BCrypt implementation in PHP 5.3.6 and earlier releases).

As you found through reading, it was attempted to dynamically test for this and it caused far too many issues; usability of Joomla could not be guaranteed on versions of PHP where we had to make guesses at what features were or were not present. IIRC Debian Wheezy was one of the more common Linux distros that folks used in testing and had the most issues with, and it is one of those that has the arbitrary 5.3.3 version strings with backports.

Re: Raising The Bar On Security

Posted: Thu Jan 29, 2015 11:31 pm
by steve-cousins
Thanks for replying. I'm not a PHP expert (by far). I've done some searching and testing and I think I have confirmed that the CentOS php version 5.3.3-40 has bcrypt. My test is (borrowed from ) :

echo "CRYPT_BLOWFISH is enabled!";
} else {
echo "CRYPT_BLOWFISH is NOT enabled!";

and the answer I get is:

CRYPT_BLOWFISH is enabled!

I'm sure this is a simplistic test but it shows that the backports have taken place. Functionally, I believe that the current version of PHP on this system more than meets the requirements of Joomla.

What would it hurt to have a variable such as ENABLE_PHP_CHECK which is true by default but could be changed by some whiner like me. Then in the checks in the Joomla code do something like (using index.php as an example):

if (ENABLE_PHP_CHECK && version_compare(PHP_VERSION, '5.3.10', '<'))

In that way, Joomla will keep its integrity but if someone wants to explicitly make a change to override the checks it will be in an easy and orderly manner.

Another way would be to use the php_uname() function and check for ".el6." in the string (among others) and have ENABLE_PHP_CHECK set to FALSE automatically.

Redhat/CentOS 6 is going to be supported for another 5 years and the php version will always say "5.3.3" even though it will actually have the same functionality of much newer versions. It seems odd that Joomla developers would want to exclude that sizable group of servers when the functionality is there, even though it has a different name.

Re: Raising The Bar On Security

Posted: Fri Jan 30, 2015 1:51 pm
by mbabker
If it were that simple, it'd be an option. Unfortunately, it isn't.

Before 5.3.7, the BCrypt hash implementation (which used a $2a prefix) had a security issue in it which was corrected in that release, but PHP decided to instead use a $2y prefix so that older hashes could continue to validate. So now to support BCrypt password hashing, you either have to always use the flawed $2a implementation or test for support of the newer $2y implementation. This still cannot account for instances where a site is moved from a server where the $2y implementation is supported to one where it isn't; there is simply no saving those users from manually resetting hashes in the database. The Debian distro is particularly troublesome in testing for this in that even though it has apparently backported this support, it doesn't quite work correctly.

So that lands us with a pretty firm cutoff on PHP 5.3.7 or distros which have proper $2y support, why PHP 5.3.10? Well, 5.3.10's release addressed a remote code execution issue in the engine itself, and IIRC 5.3.8 or 5.3.9 addressed another high level bug or security issue and we elected to just skip over those releases since we were already raising the minimum supported PHP version.

As far as the index.php file goes, that's the only place we're checking a PHP version so if you really wanted to hack it up to either remove the check completely (which is the same as your constant does) or change the version number, you could get away with it on sites you manage. However, with patches like merged into the code base, it may be that distros which didn't backport other PHP features will not work at all now.