It's time to stop chmod 777

[brian]

Spend any time on the forums here and you are regularly faced with "help my web site has been hacked".

Quite rightly the first response is to work through the security lists which in many places stress the importance of setting the correct file and directory permissions. Specifically not using 777 for anything.

Sadly many users are hacked because they have a file or directory set to 777 and then have a bad experience of joomla.

We all know that joomla, and the vast majority of extensions, are fundamentally secure but as soon as you 777 you change the situation and joomla gets the blame.

I regularly see extensions that in the code attempt to write files with 777 permissions or that advise users to 777 a file or directory for the extension to work.

This is rarely accompanied by any warning of the inherent dangers of 777 or that in many many cases it isn't actually needed anyway for the extension to function correctly.

I am not saying that the code in these extensions is insecure or bad but as soon as you introduce 777 you create insecurity.

Joomla is designed to be suitable for all and as a result we cannot assume that users understand the dangers of 777 or even what it means. They just blindly follow the instructions from the extension developer, after all we always teach people to read the manual, and then blame joomla if they are hacked.

Despite years of education that 777 is bad developers still continue, joomla sites still get hacked as a result and the entire joomla ecosphere suffers as a result.

What can we do to resolve this.

I understand that the JED team already disallow extensions that blindly 777 files or directly.

Surely now is the time for any extension that has an "option" to 777 or in the documentation "instructs" you to 777 to have a large and prominent warning about the dangers of this placed on their listing.

In addition I would "suggest" that this warning is NOT removed until not only the 777 advice or settings are removed but that information is provided by the developer how to change permissions to something more secure is provided to existing users.

Personally I would of course prefer that these extensions were removed from the JED entirely but I suspect that is a step too far for many people.




I deliberately have not listed any extension or extension developer in this post. Please can we keep it that way and keep the discussion here to the merits of placing a warning on extensions in the JED.

[fastnet]

I would suggest several things...

1. Firstly & most importantly, we all help to educate our clients on the issues of improper hosting
2. Extension developers help to promote the 777 issue & the possible after effects on their websites
3. Until such time as their extension can work without having to 777 folders/files, they have a 'warning' message displayed prominently prior to download/purchase

If one uses a properly setup host, then this could disappear quite easily - yes/no?

[Danayel]

Perhaps a list of hosts, and the "method" needed for each one to get a site working and secure.

[aoimedia]

Agreed.

Many users generally put a lot of (blind?) faith is developers, be it applications, utilities, templates, extensions or plugins. We trust developers to do the right thing and distribute relatively clean and healthy code that won't screw-up our computers or websites.

I fully expect developers to tell me of any potential negative effects that could occur through using their software.

Warnings should be in-place regardless.

[brad]

If one uses a properly setup host, then this could disappear quite easily - yes/no?

Yes

[nikosdion]

I wouldn't agree on having these extensions completely removed, as it tends to create more problems in the community than it solves. I'm thinking of developers complaining about being outcasts and users still using their extensions, unwittingly exposing their sites to risk. However, it's the user's right to know when an extension can take action on his site's setup which is known to open the doors to hackers, like chmod'ing directories and files to 0777. It is also a developer's responsibility to warn them if something like that is about to happen.

In my humble opinion, chmod 0777 should not only be a last resort method, it should also be a very temporary one, i.e. rolled back as soon as the necessary action has been performed. Let me elaborate on that. The only valid use I can think of is the need to append to a log, or a similar append operation. The FTP layer can't (and won't be able to in the future, due to PHP and FTP server restrictions) append to files. The only way to do that is directly accessing the file with PHP. In this case, the extension could chmod 0777 the file, append to it, then reset its permissions to 0644, or even 0600. Even though this is a more resource intensive operation, it is the only reasonable thing to do.

Another case where 0777 directories would not be harmful is the rare setup where the directory itself is 0777 but it also contains a .htaccess file which disallows web access to its contents, this file being chmod 0644. Even in this case, no sensitive information should be placed in the directory, or this directory should be placed in a hard to guess, above-root location, all of which limit the utility of such a construct over the proper FTP layer solution.

In any case, if the extension is automatically changing permissions or gives its users the option to change permissions to very wide settings it should be clearly noted on the JED listing. The rationale being that users will apply this setting and when their site becomes compromised they will blame Joomla!, not themselves for acting stupid (if that was an optional action) or the extension (if it was automatically applied).

[brad]

Perhaps a list of hosts, and the "method" needed for each one to get a site working and secure.

The method is simple on any good host (I'm blue in the face from blogging over the years about what makes a good host, and what hosts need to do to shape up.):

* Keep Joomla updated and secure
* Keep your components updated and secured

.. the rest is common sense (good passwords etc).

I'm sorry, I just don't feel as passionate about this issue... in my experience, it's been years since I saw this method exploited on any of our servers.. but, I do understand why it is an issue.. I just see it invariably linked to a poor hosting environment.

[fastnet]

If one uses a properly setup host, then this could disappear quite easily - yes/no?

Yes

There you go - use Rochenhost... for you Brad ;-)

Seriously though... shouldn't we, as a 'community', be suggesting known hosts that fall into the "Joomla host/services ticklist"?

[nikosdion]

Philip, even though "blacklisting" would be a good idea, it can be perceived as defamation and cause legal trouble to the project.

[fastnet]

uh? Did I mention 'blacklisting' Nicholas? not me... ;-)

[WebJIVE]

The biggest reason a smaller percentage of hosting companies still require 777 is because they are overselling server space (thanks to all the people who want UBER cheap hosting) and use Apache with mod_php instead of running PHP as a CGI with SUPHP or similar setup. Combine that with Suhosin, Mod Security, CSF and a lot of other products and you have a semi-secure setup.

When we got our own servers at web-jive.com and started hosting, that was the first thing we decided, run PHP as a CGI. This solves 2 problems, first, you can't even run 777 permissions on our system or you will get an Apache 500 error. Second, it solves the file/dir permissions problems that the Joomla FTP layer was designed for.

So, everyone has valid points but, it doesn't really matter what the permissions are per-se, the big thing is vulnerabilities in addons. That's where most sites get hacked. We recently cleaned one hacked site up on another hosting companies server with SUPHP and the hack occurred through the stock Joomla Beez template. From there, they were able to drop in a script where they could pretty much re-hack the site anytime they wanted.

[nikosdion]

Well written, but I disagree with the last paragraph. Yes, the real problem lies with the extensions. However, if a shared host allows (and encourages) 0777 permissions with its setup, your site doesn't need to be vulnerable in order to be hacked.

Let's give an example. Malroy could hack Alice's site, then install his hacking PHP file to Bob's account because his media directory was 0777, therefore writeable by Alice's user. This not-so-unlikely scenario is the one we want to protect our users from. Furthermore, it's quite easy to create an account on a shared host, then use it to mass-hack all the sites in there who have 0777 permissions.

As a result, it's not just about vulnerable extensions on your site, but protecting yourself from your neighbour's website and the truly malicious hacker trying to hack an entire server using a trojan horse approach. That said, suPHP doesn't protect your site from vulnerable extensions, it protects the server as a whole from being compromised if one site gets hacked.

It's very funny this issue is brought up today. I wrote about 0777 permissions on my blog last week, saying pretty much the same things.

[Enes]

While I recommend my Turkish Joomla Users to care on File Permissons and never let them 777, some of the popular or commonly used extensions make them completley open to whole hack attacks.
So it was enough to keep joomla and its extensions updated but now I must warn my followers in Turkey to care on "extensions who don't care about you"...
ı don't know what can be done? maybe in JED there will be a info about "extension's file permisson situation", like "register to download" and "visible link to developer". So people will be warned about them.

[WebJIVE]

@nickosdion, agree completely. The post was written to make people aware that the hosting company DOES matter and that you need to do a bit of research before jumping on board with them.

My point was even with a relatively secure setup (755, 644), hacks can still happen via PHP scripts with XSS vulnerabilities like the last one we cleaned up. ;-)

[fastnet]

My point was even with a relatively secure setup (755, 644), hacks can still happen via PHP scripts with XSS vulnerabilities like the last one we cleaned up. ;-)

Absolutely...
Beware the 'Host' (client education)
Beware the 'Extension' (JED policing)
...then extensions not listed on JED & on others websites are another nightmare!

[nikosdion]

So true! Ultimately, a vulnerable extension is a vulnerable extension. Period.

You can prevent, however, many such types of attacks by locking down access to stray PHP files. I had written a blog post last October with .htaccess redirection code I use on my sites. Its purpose is to deny PHP files installed by hackers to get a chance to execute. However, it still doesn't solve the problem with SQLi and some types of XSS attacks designed to steal your session cookie. The former can be dealt with using some mod_rewrite rules to redirect suspicious URLs to a 403 page and the latter can be dealt by installing an SSL certificate on a site.

However, as all protection measures in any field of human endeavour, they are not 100% bullet-proof. Some attacks will get through, that's why it's important to have all software installed on the site up-to-date and make frequent backups. In the end of the day it's all about minimising the chances of getting hacked and having a fall-back plan when the unthinkable happens.

[WebJIVE]

And to monitor (we do via RSS) the http://docs.joomla.org/Vulnerable_Extensions_List

[brian]

This really is not about good or bad hosting. Sure the reason why people might think they need 777 is becuase of bad hosting but that is NOT what the topic of this thread is about.

I am talking about developers who write code that 777 or who advise users to 777 as the default option. Even when they do have good hosting and dont think they need to 777.

A web site hosted on a "Good" host can still be made insecure by following a developer who instructs you to chmod 777.

[WebJIVE]

@brian, I do think the reason these devs write doc this way is because they don't take the time to let people know the pros and cons of making those recommendations, and that this is documented this way because they get SOO many support requests from people using sub-par/cheap hosting, who do use mod_php forcing that situation (i know, run-on sentence)....

:-P

[brian]

That may be the reason that they do it but it is no excuse in my book especially when their docs dont explain the dangers or that it is may not be necessary

[shackbase]

Well bottom line is, if you don't run suPHP but rather DSO for instance then you are pretty much stuck having to open up your files and directories to be writeable.

Heck you cannot even configure Joomla without first chmodding configuration.php 777 if you run apache as nobody.

Installing suPHP is actually very simple and straightforward if you have root access; I thought it would be dreadfully complicated to move a site previously run with apache as nobody to make it suPHP compatible.

You have to chmod all directories 755 and all files 664, make sure all files are owned by the user and nothing was running as nobody; might even be some issues with .htaccess had php_value or php_flag entries (not likely with Joomla but running other CMSs this can be an issue).

It would be a pain in the you know what to do it on just a single site, imagine the work needed for an entire server full of sites.

I converted an entire server with over 150 active sites earlier today and I did it in under an hour and most of that time was spent on chowning and chmodding files (single line commands to cover all sites, but it took the server a while to run each command).

Check out this tutorial http://errorcodex.com/showthread.php?t=76 - it covers everything from A-Z basically. Yes, it is geared toward cPanel for the actual suPHP switch, but the rest would work on any linux system.

Cheers,
Tony

[WebJIVE]

@shackbase - With cPanel, it's just a flick of a switch to do that and great advice! What I would like to do is get my hands on a script that I could CRON which would traverse the /home dir and for each public_html dir, issue the following commands:

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

I'm terrible at shell scripts!

Then let the nightly CRON run this script to ensure that no 777's are lurking from a component install.

[shackbase]

well basically all you'd need is to create a file that you cron to run via root to run:

find /home/*/public_html -type d -exec chmod 755 {} \;
find /home/*/public_html -type f -exec chmod 644 {} \;

of course if you have multiple drives and multiple /homex/ directories, you'd just add those below.

If you have suPHP installed though from what I understand; if a directory is 777 - if you try to do anything with that directory or file - it will just puke.

There is a little bit more to installing suPHP on even a cPanel server than just flipping a switch - you have to prep the server first by running the commands above and making sure all files are owned by the user and not by apache - the forum post above does a great job of showing you the quickest and easiest way to do that.

Cheers,
--Tone

[WebJIVE]

That would be nice if you did that per account setup but, not for going through the /home dir and doing it all at once. Your correct about suPHP (in one of my earlier posts) but, you can do things like 666, 755, etc.

[fastnet]

We wouldn't expect a novice to do any of this... this is why Brian is saying the root issue is the extensions & we must make things transparent to the user/downloader.

We mustn't forget that a lot of people haven't got a clue about hosting or extensions - but mustn't be told to chmod 777 ever. They just go to JED, find the extension that does what they want & follow instructions - if they are told to chmod 777 a folder or file, they will without any knowledge of the possible consequences.

[masterchief]

Surely now is the time for any extension that has an "option" to 777 or in the documentation "instructs" you to 777 to have a large and prominent warning about the dangers of this placed on their listing.

I understand the issue and sentiments, but I'm not convinced that this is yet another thing to lump on the JED editors. It's great to focus so finely on this issue but what are the implications for the workload of the JED people if the assumption is that it's the responsibility of the JED people to actually find this problem. Personally this is just a subset of vulnerability issues that can be encountered using a Joomla site.

To be clear, 777 is not advisable but sometimes the only (temporary) workaround on a minority of sites which aren't set up well (as long as you remember to change it back, aka, remember to lock your safety deposit box after you've done your business). When I've encountered this I encourage people to either employ an experienced Sys Admin to fix up their system or change to a host that does it for them.

An extension that advertises 777 as a carte blanche solution is really not doing the right thing (no argument there). An extension that allows you to configure chmod-ing is perfectly fine (though I'd avoid it personally because if your site is set up correctly, you don't need it) but defaulting to 777 is unwise. An FAQ on a vendor site that says something to the effect of "if all else fails, temporarily 777 folders, do X, Y and Z and then change it back and understand these risks" is also acceptable. Ultimately a vender cannot have full control over their customers' sites. However, chmod-ing has no affect on security of the of the executed code itself - other vulnerabilities could exist regardless of what the file permissions are.

For me, a reasonable solution could be:

* To ensure we have a good project wiki page explaining file permissions (if not there already) that extension developers can easily reference if they so choose (ie, make it easy to do "best practice").
* Define exactly what is bad practice as far as an extension is concerned.
* Allow that bad practice to trigger getting listed on the Vulnerable Extensions List (VEL).

I don't think this is specifically a JED issue other than handling this how any other extension on the VEL is handled (this isn't a special case, it's just one thing in a long list of possible security issues). I think the VEL would be sufficient incentive for developers to do the right thing (as long as we have defined what the wrong thing is).

[WebJIVE]

@andreweddie - I completely concur!!

The topic really split into more what not to do, and deviated from the original thread by Brian. Including myself, we got off into a tangent about the merits of 777, hosting, etc. instead of sticking to the post about the JED requirement suggestion.

I "100%" concur with you that this shouldn't be a JED maintainer responsibility. The JED is such a HUGE part of the Joomla organizational maintenance that, if we add this 1 thing, it would mean that JED maintainers would need to go to the developers site, surf around to find this in the doc if it exists.... you get the picture.

What would probably help more people is a WIKI page, which someone could start (like the security page), where people could list addons which either list this as a workaround in FAQ's, DOCs etc, flat out say that's the way to set the product up, or more nefariously, does a chmod 777 upon install.

Then it could be community verified and maintained like the security page. That would be a better way to handle alters IMHO.

Thoughts?

[brian]

i'm not saying that the JED team have to surf and monitor but if it is reported to them then they place the warning notice on the extnesion.

remember that we all suffer from the bad reputation created as a result of a few bad extensions or poor advice from extension developers.

[masterchief]

i'm not saying that the JED team have to surf and monitor but if it is reported to them then they place the warning notice on the extnesion.

Would it not make sense to just handle it like a VEL extension?

[brad]

If you really want to make a difference (educate), why not try to help before advocating someone else do some kind of 'enforcing'.
What I mean is.. get a page up on the docs.joomla.org wiki, then one on one help educate some of these developers.

As for hosts.. just point them to my blog posts.. ironically, some over 2 years old still apply (reg_globals, suphp, blaming Joomla for poor server security etc). Web hosts are far more reprehensible though.. so if you really do want to make a difference, start with the developers of 3rd party components.

Just my idea, as we're only preaching to the converted here.