Advertisement:

Author Topic: Why chmod 777 is NOT a security risk  (Read 359169 times)

Offline [Unknown]

  • SMF Friend
  • SMF Master
  • *
  • Posts: 36,102
  • Gender: Male
Re: Why chmod 777 is NOT a security risk
« Reply #40 on: August 21, 2005, 01:33:44 AM »
Actually the hosting company I was referring to is Interland.

Ugh.  That's not the best hosting company to make an example of.

Quote
that files with a permission setting of 777 can be deleted by any user / application.

That's the same as writing to it, essentially...

-[Unknown]

Offline [Unknown]

  • SMF Friend
  • SMF Master
  • *
  • Posts: 36,102
  • Gender: Male
Re: Why chmod 777 is NOT a security risk
« Reply #41 on: August 22, 2005, 11:05:46 PM »
I've been asked to clarify this again, so let me say the following:

1. Whether you are on a shared server or a dedicated server, on your server there are several directories which must (unavoidably) be 777 - for example, /tmp at the least, and in most situations attachments and possibly other directories.  So, we understand that some things must be writable by "nobody" (Apache.)

2. If a file is writable by "nobody" (Apache), or owned by nobody (as attachments will be, since they are created by nobody) they may potentially be written to.  This is, again, not avoidable.

3. If your server is compromised, as described above, many of these files may be overwritten, deleted, or otherwise affected negatively by the hacker or script.  Again, assuming compromises are unavoidable, this is too - given the above.

So, if we take all of the logical points above, we understand that the server will need to undergo a COMPLETE AUDIT if it is ever hacked.  So far, I hope everyone can agree with me, right?  If any host believes that you can keep a server running immediately after a script got system or file access, they are not worth paying any money.  I hope we can all agree with that statement too, right?

Continuing to assume that file or system access compromises are unavoidable, we know that such access also potentially gives access to delete, modify, or access the entire database.  This means that:
  • The entire forum could be deleted, which is recoverable if you have backups.
  • The list of email addresses, password hashes, and other confidential information could be read, which is not only unavoidable, but also much worse than anything else.
  • Forum data could be maliciously modified, in fact things could be done which would be very similar to file modification (for example, someone could replace a board's description with cleverly designed HTML to cover the entire page.)


So, clearly, database access is the worst thing that could happen to you.  If a hacker obtains database access they can do practically anything possible by way of file access.  I think this has not been sufficiently clear either.  While some may disagree with my statement about file access, I hope no one will disagree that the disclosure of personal information to a hacker of malicious intent is hands down worse than the server itself physically exploding.

Obviously, conventional wisdom dictates that files should not be writable by anyone unless necessary.  I have never suggested otherwise, and anyone who says I have is miscontruing my meaning.  However, my meaning is clear - the "additional" problems possible when files are 777 are minimal at best.  They are, as described:
  • Files (which are easily obtained from the download page, and never change) may be deleted.  Said files should be backed up anyway.
  • Files may be maliciously modified.  This, as above, is unavoidable (because some directories and files will be 777 nevertheless, like /tmp and attachments) so should always be considered.  After being hacked, a server should be wiped and *CLEAN* backups should be restored.  No files should ever be trusted, 777 or not.


Additionally, whether 777 or not, files with confidential or important information may be read.  This is unavoidable unless Apache does not need to be able to read the files.  Again, if a hacker of malicious intent is able to procure confidential information, this is much worse than malicious modification.  In some cases, users are not allowed to, or simply do not, have separate passwords between FTP and MySQL.  In these (too common, especially in shared hosting) cases, the ship has sunk anyway.

Benefits which come, however, from having files 777:
  • Database error reporting works better (it won't send you an error every time it cannot connect, since connection errors usually come in groups.)
  • Attachments may be posted, and avatars may be uploaded.
  • Templates and themes may be installed and modified from the administrative interface.
  • Updates may be installed, clearly increasing security.
  • Modifications and packages may be installed, improving general use of the forum.


Of course, many of the above - such as updates - do not require files to be 777 indefinitely.  For this reason, the administrative interface includes ways to change the file permissions en mass, to make updates easily installable or to increase (although, as laid out above, by only a very small margin) security.  The use of said features is encouraged, but some hosts suggest to their users that files should NEVER be 777, which is what this topic is disagreeing with.

Anyone who says that having files 777 on a shared server is a way to cause or worsen a security problem clearly has no plans to take proper measures to clean up after hacking has occured, and may also think that their system is safe as long as files are not 777.  Such blind faith in file permissions is foolish at best.  I strongly recommend against paying any money to any such host, unless you wish to promote such bad practices in the industry (and possibly cause your self nasty problems after or during an attack, even with no files 777.)

-[Unknown]
« Last Edit: August 22, 2005, 11:09:01 PM by [Unknown] »

Offline tentronik

  • Full Member
  • ***
  • Posts: 499
  • logic is
    • [Roboter]
Re: Why chmod 777 is NOT a security risk
« Reply #42 on: August 23, 2005, 12:54:23 AM »
But other php software didnt require this settings and you can still do the required things like uploading images and modifing scripts and altering the database entrys.

How is Mambo doing it or vBulletin?
And isnt 755 a diffrent?

And on the bottom line the data should be safe and this should be a minor attention level for the forum core.

Otherwise things like you mentioned about the possibility of exploits will happen and there will be many who would not even requognize this.
This can cause very high damage in many ways.

If there arent possibilitys or not satisfying possibilitys then we have no choice but this is not clear for me yet ;D


Cheers
« Last Edit: August 23, 2005, 12:57:53 AM by tentronik »

Offline [Unknown]

  • SMF Friend
  • SMF Master
  • *
  • Posts: 36,102
  • Gender: Male
Re: Why chmod 777 is NOT a security risk
« Reply #43 on: August 23, 2005, 01:05:05 AM »
But other php software didnt require this settings and you can still do the required things like uploading images and modifing scripts and altering the database entrys.

Other softwares do.  For uploaded avatars to work in phpBB, some folders must be 777.

The very same with Mambo.

Quote
And isnt 755 a diffrent?

On some servers, no it isn't.  These servers remove the possibility to distinguish Apache from the user themselves, but make it easier to protect other people on the same shared server.

On others, yes - it's different, and means that only the owner can write to the file or directory.  Unfortunately, this means that PHP exactly what it says - and so Apache (unless it's using suExec) cannot write to any of the files or folders.

Quote
And on the bottom line the data should be safe and this should be a minor attention level for the forum core.

Otherwise things like you mentioned about the possibility of exploits will happen and there will be many who would not even requognize this.
This can cause very high damage in many ways.

If there arent possibilitys or not satisfying possibilitys then we have no choice but this is not clear for me yet ;D

I'm not clear on what you meant by that.  Of course the data should be safe, but nothing more can be done to protect the important data.  The unimportant data (in files) is definitely secondary, and as I said should be restored from a known clean backup at the event of any problems.  In fact, I regularly update all of the files on this site when updating it, because it's the safest way.

Unfortunately, as noted above, it is not the easiest.  And what's not easy, especially when we're talking about (and this is a huge generalization!) shared hosting customers, won't be done half as often as it should.  So make it easy, that will be better than making it hard and 1% more secure.

-[Unknown]

Orstio

  • Guest
Re: Why chmod 777 is NOT a security risk
« Reply #44 on: August 24, 2005, 09:09:32 PM »
Quote
But other php software didnt require this settings and you can still do the required things like uploading images and modifing scripts and altering the database entrys.

How is Mambo doing it or vBulletin?

Mambo requires that most folders and files be writable by Apache, at least during configuration and/or installation of modules, components, bots and templates.  This is nothing specific to SMF.

Offline Joshua Dickerson

  • SMF Friend
  • SMF Super Hero
  • *
  • Posts: 12,775
  • Gender: Male
    • joshuaadickerson on GitHub
    • joshuaadickerson on LinkedIn
Re: Why chmod 777 is NOT a security risk
« Reply #45 on: September 04, 2005, 07:34:09 PM »
I can understand both sides. If you don't want other users on the same server to manipulate your files, chroot/jail. If you are worried about changing of the scripts, you'd need to have access to the server already. A vulnerability with the PHP part (no problems with SQL injection). Lets say I managed to get a user to run a script via the package manager without them knowing (which is already protected against).

If I got this far, I could have EASILY gotten the password from the user. I can bruteforce the password if not. I can't edit the SMF files, attachments, etc and I can't run an shell commands. I can still drop the database. Since not everything is 777 or 775, I can't go around dropping other files outside of the SMF scope. Since it is chrooted, I can't go to other users' root directories and mess up their accounts. So all lower permissions did for SMF is make it so that I can't update the files. That is about it.

If the files were 777 the max damage would be - dropped database, rm'd attachments and SMF files. No other files would be affected.
The benefit would have been that I can upgrade before a hacker got to me and I have many more features.

So, with anything, you have to weigh the consequences. Do you care about the SMF files when your database can easily be destroyed?

777 isn't something you'd use with EVERYTHING. Since it makes SMF's features work on certain hosts, it is useful. I wouldn't use it on things where I didn't need it.
Need help? See the wiki. Want to help SMF? See the wiki!

Did you know you can help develop SMF? See us on Github.

How have you bettered the world today?

Offline raymor

  • Newbie
  • *
  • Posts: 1
Re: Why chmod 777 is NOT a security risk
« Reply #46 on: October 04, 2005, 02:41:49 PM »
"Uknown", do me a favor, if you would.  Before you post again on this topic
read "man chmod" and be sure you clearly understand how executable
and writeable permissions work on directories.  Hold on, I know you're probably
thinking "I know all about permissions."  Stop.  Go read it.  Read it twice if you must
to be absolutely 100% sure you thoroughly understand exactly what "executable"
means for a directory and what "writeable" means for a directory.  Your comments
about the permissions of a user's home directory affecting the accessibility of directories
beneath it shows quite clearly that you're confused about directory permissions.
It is absolutely 100% impossible to chmod a users home directory in any way that
would affect the writeability of files or directories beneath it without making the
whole web site totally inaccessbile. 

Also consider that perhaps the worst thing that a cracker can possibly do is NOT
to delete posts.  The worst thing they can do is what they indeed do most often -
install a bunch of shells all throughout your system, then use those to attack other servers.
Your web host or upstream then cuts your server off, you try to fix it, perhaps
totally deleting the whole directory for this script, but that does no good.
As soon as the server is turned back on the cracker will be using it to attack others
again because at this point they've installed shells in other directories including
/tmp, /var/tmp, and any other world writeable directories.  These crack scripts
may well be self replicating, so as soon as you delete one another copy somewhere
else puts it back.  On most servers, it becomes impossible to secure the server and
get the site back on line without totally wiping the disk and reinstalling everything.
A cracker deleting a few posts from the database is the LEAST of your worries,
not the worst they can can do.

In response to the poster that said a cracker would need to have some way to upload
files to the server, try ANY AND ALL PHP scripts.  The following PHP script will
let a cracker upload files to your server:
Code: [Select]
<?php ?>PHP (stupidly) accepts file uploads and saves them before it even reads the PHP code.
If you have any PHP scripts anywhere on the server a cracker can very easily upload
any file they want to.  Even if you were to disable uploads completely in php.ini is
still easy to do if you have fopen_url turned on, normally done by injecting the URL
to the crack script into a require() statement.


Offline tentronik

  • Full Member
  • ***
  • Posts: 499
  • logic is
    • [Roboter]
Re: Why chmod 777 is NOT a security risk
« Reply #47 on: October 04, 2005, 07:13:50 PM »
Yesterday i installed joomla and most of the folders got chmodded as in SMF.
And this varies from server setup (php.ini).
Also SMF automaticly generates and checks file existence, which let me think SMF uses a new method of securing?

Anyway even joomla.org uses SMF as forum software ;)

And we have to differ between server cfg and SMF which might run on a insecure backend.
Also there are php methods of securing and there are diffrent versions and setups.

Maybe we need a readme about secure "optimized" SMF server setup?
Quote
If I got this far, I could have EASILY gotten the password from the user. I can bruteforce the password if not.
How, isnt there a blocker (eg. 3 times wrong entry and you get this lost password thingy...).

Cheers
« Last Edit: October 04, 2005, 07:24:16 PM by tentronik »

Offline carlatf

  • Jr. Member
  • **
  • Posts: 213
  • Gender: Female
    • Buscador de Internet Todalanet
Re: Why chmod 777 is NOT a security risk
« Reply #48 on: December 27, 2005, 10:18:31 AM »
Hi People,

I changed my permissions following something of this post and now I can't see my avatars. (I can upload them but I don't see them)

Can anybody tell me what permission is wrong?

I make a little tree: (it's /var/www/users/BLABLA/MYDOMAIN.com/public_html/foros)

drwxr-xr-x   24 root root  4.0K Jul  6 07:02 var
drwxr-xr-x  12 root    root    4.0K Oct  7 08:40 www
drwxr-x--x     8 root      root   4.0K Oct 18 19:33 users
drwxrwxr-x   3 apache root 4.0K Aug 21 00:09 BLABLA
drwxrwxr-x  7 apache BLABLA 4.0K Dec  4 00:00 MYDOMAIN.com.ar
drwxrwxr-x  17 apache BLABLA 4.0K Dec  6 02:35 public_html
drwxrwxrwx   8 apache BLABLA 4.0K Nov 27 07:24 foros
drwxrwxrwx   2 apache BLABLA 4.0K Dec 27 00:22 attachments

Before I had the user BLABLA as the owner and apache as the group in public_html and all the subdirectories but after reading this post I changed it.
Why  I cant see the attachments if it's 777 that directory?

best regards,
Carla

Offline dtm.exe

  • SMF Hero
  • ******
  • Posts: 5,465
Re: Why chmod 777 is NOT a security risk
« Reply #49 on: December 27, 2005, 10:19:57 AM »
Hi People,

I changed my permissions following something of this post and now I can't see my avatars. (I can upload them but I don't see them)

Can anybody tell me what permission is wrong?

I make a little tree: (it's /var/www/users/BLABLA/MYDOMAIN.com/public_html/foros)

drwxr-xr-x   24 root root  4.0K Jul  6 07:02 var
drwxr-xr-x  12 root    root    4.0K Oct  7 08:40 www
drwxr-x--x     8 root      root   4.0K Oct 18 19:33 users
drwxrwxr-x   3 apache root 4.0K Aug 21 00:09 BLABLA
drwxrwxr-x  7 apache BLABLA 4.0K Dec  4 00:00 MYDOMAIN.com.ar
drwxrwxr-x  17 apache BLABLA 4.0K Dec  6 02:35 public_html
drwxrwxrwx   8 apache BLABLA 4.0K Nov 27 07:24 foros
drwxrwxrwx   2 apache BLABLA 4.0K Dec 27 00:22 attachments

Before I had the user BLABLA as the owner and apache as the group in public_html and all the subdirectories but after reading this post I changed it.
Why  I cant see the attachments if it's 777 that directory?

best regards,
Carla


Please include a link to your forum as well as a test account's login details.

Offline Anguz

  • SMF Friend
  • SMF Hero
  • *
  • Posts: 3,430
  • Gender: Male
    • cristianlavaque.com
Re: Why chmod 777 is NOT a security risk
« Reply #50 on: December 27, 2005, 04:10:07 PM »
Did you maybe use hotlink protection in cPanel? It sounds to a similar problem I had in the past with it.
Cristián Lávaque http://cristianlavaque.com

Offline alchemy

  • Semi-Newbie
  • *
  • Posts: 43
Re: Why chmod 777 is NOT a security risk
« Reply #51 on: December 27, 2005, 09:52:28 PM »

The ideal setup would be to have the server run in a chroot (jailed) environment.
Apache and PHP both run under SUExec.
Owner and group are both your user, since Apache runs under your user account.


Chroots are always a good idea. Php's safe_mode has a script uid check   similar to SUExec, but is not as extensive.

SUExec might be worth some further discussion to assess it's worth,
since binarys with SUID/SGID perms set are questionable in my book.

http://archives.hwg.org/hwg-basics/3BC1FDE8.E5CD2D7C@webgraffix.com
Quote
First of all, it is trivial to exploit suExec to gain root privileges of a system.
suExec is NEVER secure unless you have a 100% closed system (you can trust everyone who
has write privileges on the server).

Many exploits are published on various hacker sites and appear on the bugTraq mailing
list at least a few times per year.

Secondly, you can use suExec even when you are using PHP as an Apache module. suExec is
not a CGI-specific tool, it is a process-specific tool and can be (and usually is)
installed as part of httpd (Apache in most cases).

I believe that you are indicating that suExec is a tool to that can only be accessed by
CGI scripts. If so, this thought is wrong. (If you are not indicating this, accept my
apologies). If you install suExec as part of httpd (which is almost always how it is
installed), then anything that httpd runs can be suExec'ed, including the PHP module.

You are correct that the default installation of PHP writes files as the user
"nobody."  I really don't understand what you're stating about writing the files as
user "jtpolk" instead of user "nobody".  I do not see how writing files as user
"nobody" versus writing the files as a specific user makes any difference.  If I can go
to a web site and cause the web server to do "bad" things to the file system as can any
user who can write to the specific directory or file, why does it matter what username
is being used?

Look at it this way: "UserA" has write privileges to the /images directory. We suExec a
script to write files to the /images directory as UserA.

UserB writes a mailicious script that suExec's to be UserA and deletes the contents of
the /images directory. How is this more secure than UserA having an /images directory
owned by "nobody" and UserB creating a script that deletes the contents of the
"/images" directory?

The added problem is that if UserB writes such a script, he can now delete ANYTHING
that is owned by UserA!  If the /images directory were owned by "nobody" and everything
else was owned by UserA, the potential damage would haved stopped at the /images
directory.

My point is that neither one is really "secure," but suExec is not better than giving
write premissions to a non-privileged account. As a matter of fact, in certain
instances, it can be much worse.

As a matter of fact, suExec'ing the script as a real user then gives me the ability to
use my malicious script to overwrite ANYTHING that is owned by that user (usually the
user's entire web content!).  When you use the default installation of PHP, the user
"nobody" doesn't have privileges to write anywhere on the file system execpt as
permissions are specifically granted by a sys admin.  This does mean that certain
files or folders are succeptible to abuse, but it also means that the sys admin has to
be fully aware of which files are succeptible before they are.

As I said before, neither solution is secure, but most people who use suExec do not
truly understand what the implications of their decision could be.  I know that you are
fairly knowledgeable dealing with scripts, etc., so you may be the exception to this
rule.

I also would never profess to know as much as I would like to know about security.  I'm
trying to learn every chance I get by asking as many questions as I can.

Offline higherauthority

  • Jr. Member
  • **
  • Posts: 268
  • Gender: Male
    • Midwest Airsofters
Re: Why chmod 777 is NOT a security risk
« Reply #52 on: February 14, 2006, 06:29:21 PM »
This is good info however I am a bit confused also I am using a host that uses a 2003 server with plesk (Ya I know a windows web server ugggggg   we wont talk about that now)  But hey its free because I know the guy running the hosting company.

my boards is in a sub directory http://Http://mydomain.com/boards

right now I have the directory permissions of boards set to "full controll"  everything works great but I am sure that this is not good. I probably have all my doors open don't I ?

I am a noob so bear with me.....

in the plesk cp  I goto web directories and choose boards directory

right now I have the Plesk IIS User (IUSR_mydomain)    set to Full controll
my options are 

Permissions for IUSR_mydomain 
Full Control   
Modify   
Read & Execute   
List Folder Contents   
Read   
Write   

I am a bit new to your terminology of chmod 777 and such   

So chmod 777  is read and write ?

any guidance on what directories I can slim down ?

I have hot link protection enabled and everything is working will this be sufficient for now with the settings I have ?

Sorry for so many questions ...........but I want to make sure I don't get hacked and you guys seem to know whats going on more than me.....   Reading this thread helps but I am a bit unclear..


Thanks in advance



Offline kegobeer

  • SMF Friend
  • SMF Hero
  • *
  • Posts: 3,994
  • Gender: Male
  • I am ninja!
    • The Kazebeer Family Website
Re: Why chmod 777 is NOT a security risk
« Reply #53 on: February 14, 2006, 08:43:54 PM »
CHMOD is not applicable to Windows operating systems.  This is a *nix command.
"The truth of the matter is that you always know the right thing to do. The hard part is doing it." - Norman Schwarzkopf
Posting and you (Click "WATCH THIS MOVIE")

Offline higherauthority

  • Jr. Member
  • **
  • Posts: 268
  • Gender: Male
    • Midwest Airsofters
Re: Why chmod 777 is NOT a security risk
« Reply #54 on: February 14, 2006, 10:03:12 PM »
I figured as much was not sure but am I ok with how I have the permissions set?

Offline sm2k

  • Semi-Newbie
  • *
  • Posts: 40
Re: Why chmod 777 is NOT a security risk
« Reply #55 on: February 15, 2006, 01:57:37 PM »
I've always designed my upload scripts such that an uploaded file is sent to an uploads folder that is completely locked up via .htaccess.  The files are then moved to the appropriate location in the web via ftp.  Thus there is only one folder with 777 permissions and it's not web accessible, and there aren't a bunch of apache owned files laying around. 

The potential weakness then is reduced to one point of entry, and I can focus my validation efforts there.  It's of course very important to be strict about all user input, and to use php's built in mechanisms for upload file validation.  This can be improved by using a restricted FTP user, if you have the ability to create one on your server.  It can be furthur improved by using htaccess to restrict the file types that can be served from your destination folders (e.g. the final resting places of your uploads).

The current trend of portals and forums to have these wide open directories is really just for ease of use.  Unfortunately it encourages mistakes and abuse.

Recommending 777 makes my skin crawl. 

Offline alchemy

  • Semi-Newbie
  • *
  • Posts: 43
Re: Why chmod 777 is NOT a security risk
« Reply #56 on: February 15, 2006, 05:45:16 PM »
chmod 777 is for people that are either "lazy", or don't understand the concept to always use the "least permissions" possible.

Not one single file, or directory, is 777 in my SMF installation.

If SMF required 777 to function It wouldn't be on my server!

I chose SMF because, out of the major players, it has the best security track record. Besides that it also makes a great forum.

If SMF will work in the restrictive environment on my server, it will work on any server. And it does.


Offline Anguz

  • SMF Friend
  • SMF Hero
  • *
  • Posts: 3,430
  • Gender: Male
    • cristianlavaque.com
Re: Why chmod 777 is NOT a security risk
« Reply #57 on: February 15, 2006, 06:37:28 PM »
alchemy, I'm sure several are curious about how you have it. Could you tell us what permissions you used for what files? For those that don't want it to be all 777.
Cristián Lávaque http://cristianlavaque.com

Offline Amacythe

  • SMF Friend
  • SMF Super Hero
  • *
  • Posts: 19,060
  • Gender: Female
Re: Why chmod 777 is NOT a security risk
« Reply #58 on: February 15, 2006, 08:34:07 PM »
My host doesn't allow 777 and all my files are 755

Offline duminas

  • Semi-Newbie
  • *
  • Posts: 22
Re: Why chmod 777 is NOT a security risk
« Reply #59 on: February 16, 2006, 01:28:16 AM »
I don't quite follow you guys, but every time I've had 777, files have randomly appeared in my forum directory. This is with the parent (public_html) being 755. It's a shared environment, yes, but would not the chroot jail stop that? If not such, the fact that each person is their own user and group would, if I understand Unix file permissions. The same thing happens to CPG and two other SMF installs, so I'm a bit skeptical of this "777 isn't a risk!" idea.

Also, my host complains at me whenever SMF's "Attachments" directory is 777, due to it being a (har) security risk, and this is where I get odd files half the time. Obviously, they know something I do not, and I haven't had problems when things are--for example--775. But then PHP can't write to the Attachments directory, due to the files not being owned by the server. Due to this, attachments are disabled on my forum, and avatars are linked by other means. At home, I've got files with 000 and as they're owned by my server user they work fine; even attachments work. Granted, I need to be the superuser to toy with them as the webserver user has no shell, but that's beside the point.

Just thought I'd ask how having 777 is ever a good thing compared to 644, in the case of PHP scripts. ^^