Simple Machines Community Forum

Archived Boards and Threads... => Archived Boards => Parham's PHP Tutorials => Topic started by: [Unknown] on November 20, 2003, 03:41:19 AM

Title: Why chmod 777 is NOT a security risk
Post by: [Unknown] on November 20, 2003, 03:41:19 AM
Alright, so say I tell you that to have attachments work properly, your attachment folder needs to be 777.  The first thing people ask me is...

  - Isn't this a security risk?
The short answer is: no, not really... it isn't.  Keep reading for the long answer.

  - So, what, you're saying EVERYTHING should be 777?!?
Not hardly.  Just some things in the forum's directory.  Not, of course, that you should do so with the entire directory - but it won't matter much if you do, so long as your server is configured reasonably correctly.

  - But... wait a minute.  The three numbers stand for "Owner," "Group," and "Everyone."  Doesn't that mean anyone can write to the files if I make it 777? (writable by all!?)
Well, technically, yes.  But, the person first has to get into your server and be able to touch the file in the first place.  They also have to have access to the directory the file is in, and the directory that file is in.  At some point, you should have a directory (probably your username) which isn't 777.

  - Isn't it safer, at least, not to use 777?  What if a hacker got in?!
If a hacker gets in and wants to cause you trouble.... there is nothing you can do.  You can have the file permissions as strict as you want, but the database will be wide open.  So, yeah... you can protect the files that don't change from being deleted, but not your posts.
Which is more important?  The files you can download again from here or the data you cannot get back?


  - Isn't it unlikely a hacker would get into my server so much they could delete posts?
Not that unlikely, but no more or less likely than if they could use 777 to their advantage.  Think of the database as ALWAYS 777.

  - Doesn't MySQL have permissions?  Can't I make it so they can't delete?
The forum won't work if you do that.  It needs to be able to delete.  If it can delete, so can the hacker.  Dillema, huh?

  - I believe you, but my host doesn't.  They don't want me to make everything 777, they say it's not safe.
So have them read this.  If they can't refute it, prove it wrong, or at least even challenge it then I guess they have to let you do 777 ;D.

  - Even if 777 isn't a problem, why should I bother?
Because it makes things, like for example the package manager and attachments, work better.

Any other questions? (so far I made all these up, sorry if they aren't realistic :P.)  Feel free to ask and I'll answer away.  I challenge you to prove me wrong.... show me that somehow 777 is all that bad.

-[Unknown]
Title: Re: Why chmod 777 is NOT a security risk
Post by: David on November 20, 2003, 03:48:49 AM
If you are on a shared server that is not chrooted on ftp or ssh login other users will be able to navigate throughout your directories.  If you have your attachments directory chmodded to 777 but its parent to 770 then they will not be able to do this as they will not be able to reach the parent.

This is how I would chmod my files and directories in a shared environment.
Read only files are 440.
Read only directories are 550.
Write files are 660.
Write directores are 770.

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.

If your server does not support SUExec then set the owner of the files and directories to your account and the group to the group that Apache runs under.  This still means that you can leave everyone at 0, no access, as Apache will gain access via the group.  Running in this sort of setup will not loose anything that chmodding your files to 777 allows.
Title: Re: Why chmod 777 is NOT a security risk
Post by: [Unknown] on November 20, 2003, 03:50:37 AM
The problem is that a lot of servers are not configured properly.  But, I'll add to it that you should, by all means, have your public_html folder set to 770 or less.  But subdirectories and files can be 777...

-[Unknown]
Title: Re: Why chmod 777 is NOT a security risk
Post by: David on November 20, 2003, 03:55:15 AM
Quote from: [Unknown] on November 20, 2003, 03:50:37 AM
The problem is that a lot of servers are not configured properly.
You hit the nail on the head.  Many servers do not have users and groups set correctly nor does the host really understand what they do.
Title: Re: Why chmod 777 is NOT a security risk
Post by: bostasp on November 20, 2003, 04:11:39 AM
How would you say - in brief terms - how a server should be correctly configured?
Title: Re: Why chmod 777 is NOT a security risk
Post by: Aquilo on November 20, 2003, 04:19:46 AM
I'm wishing I had taking Jason's offer instead of going with the host I'm at now, I don't know what SUExec David is referring to but the one run on my host is plain STUPID!!!!

from my host...
QuoteBeyond webroot protection, which is very necessary for security reasons, we run a standard Apache Suexec setup.

why under a Suexec setup even a text file has to have 777 for a script to read & write to it? why can't 666 be good enough! right?

here is an example of the seemingly highly regarded SUExec being stupid...
Quote
an example,
I wan't a script located at
/public_html/index.php
to read and write to
/public_html/MySkins/
same user in the same account,

now MySkins contain php script so setting it to 666
should let the world read and write to it but not execute script in there this is so no one can edit the file with bad code and then execute it! this would be -rw-rw-rw- but something is making it so nothing can read the dir unless it has execute permissions.

the thing I don't understand is why I have to give execute permissions just to read!?
answer "maybe try chmod 1666?"

Quotestill overridden.

FTP log:
SITE CHMOD 1666 MySkins
200 SITE CHMOD command successful
NOOP
200 NOOP command successful
CWD /public_html/MySkins
550 /public_html/MySkins: Permission denied

if I use 1666 or 2666 or 4666 it's still Forbidden.
answer "I just changed some of the permissions on the directories..."

Quote
under 666
/public_html/MySkins <- Access

/public_html/MySkins/theme <- Access

/public_html/MySkins/theme/css <- Permission denied

and php can now execute under 666

Now I don't know if this is SUExec being stupid or the admin don't know how to run it but I don't see how any of this helps protect anything! if any thing it's undermining the hole CHMOD concept of how and who to give permissions to!

or am I wrong for thinking SUExec and this kind of setup is stupid?
Title: Re: Why chmod 777 is NOT a security risk
Post by: David on November 20, 2003, 10:54:05 AM
If I were running a shared server I would use a chrooted environment for ftp, I would not give ssh access except on a case by case basis.  ssh would also be chrooted.  What chroot, also known as jailing, a user does is keep them in their home directory.  Instead of logging them in to their home directory but also allowing them to browse to the parent of their home directory, they won't even be able to know that there is a parent directory.  There are scripts to break out of these jailed environments but like anything, as there is a new vulnerability the software is patched.

I would then run Apache AND PHP with SUExec.  Many people believe that you can just compile Apache to use SUExec and you are set but you must ALSO compile SUExec support into PHP.  With SUExec your Apache processes will run as if they were your user.  Thus when serving one of aquilo's pages, Apache will act as if it were aquilo.  This allows a server admin to really lock down the file permissions.  No longer does the world permissions have to be 1 or 5 on parent directories since apache can now gain access itself.

Aquilo, the execute permission is used in two ways.  Either for a cgi or shell script or if on a directory it allows the user/group/world to cd into it.  You should never have to give execute permissions on a php script.  Also your host telling you to try 1666 makes no sense as the first 1 marks the file as a changed since the last backup, it is setting an "Archive Bit" and thus has absolutly nothing to do with solving your problem.

http://www.mkssoftware.com/docs/man1/chmod.1.asp
Title: Re: Why chmod 777 is NOT a security risk
Post by: Aquilo on November 20, 2003, 11:22:31 AM
I guess the solution to the problem is to just use .htaccess and AddType text/plain .php if I don't want php run in a directory! I thought chmod would stop php from executing if it didn't have permission.

so that problem is solved, now why it has to have execute permission for anything to run!? :D

Thanks David!!
Title: Re: Why chmod 777 is NOT a security risk
Post by: Anguz on February 09, 2004, 03:27:20 AM
I'm wondering about permissions right now, so I'm happy I found this thread...

one of my webhosts does jail accounts and I have a limit to the permissions I can set even, which is my problem

directories can't be higher than 755 and files 644

will it be possible to have SMF run correctly with those limitations? how?
Title: Re: Why chmod 777 is NOT a security risk
Post by: Spaceman-Spiff on February 09, 2004, 07:21:37 AM
yes, you can have SMF running properly, but you cant use some features like:
- attachment
- package manager
- Settings.php editor (Forum Preferences and Settings)
Title: Re: Why chmod 777 is NOT a security risk
Post by: Anguz on February 09, 2004, 02:46:01 PM
kuso~ (>_<#)

I can edit settings without the editor fine, but attachments and package manager I really want to be able to use (-_-;)
Title: Re: Why chmod 777 is NOT a security risk
Post by: Jeff Lewis on February 09, 2004, 03:28:15 PM
Quote from: Anguz on February 09, 2004, 03:27:20 AM
one of my webhosts does jail accounts and I have a limit to the permissions I can set even, which is my problem

You need to move that site to your other host ;)  ;D
Title: Re: Why chmod 777 is NOT a security risk
Post by: Anguz on February 09, 2004, 04:01:45 PM
lol that's actually what I was thinking about (^_^)

it's just that I have so much wasted space and bandwidth over there, that I thought I'd use it
Title: Re: Why chmod 777 is NOT a security risk
Post by: Killer Possum on February 09, 2004, 04:46:43 PM
Quote from: Jeff Lewis on February 09, 2004, 03:28:15 PM
You need to move that site to your other host ;)  ;D
Quote from: Anguz on February 09, 2004, 04:01:45 PM
lol that's actually what I was thinking about (^_^)

*coughlewismedia (http://www.lewismedia.com/hosting.php)cough*
Title: Re: Why chmod 777 is NOT a security risk
Post by: Anguz on February 09, 2004, 05:36:30 PM
that's precisely the other host we're talking about (~_^)
Title: Re: Why chmod 777 is NOT a security risk
Post by: bostasp on February 09, 2004, 05:41:01 PM
I need to move something to that other host too ;)
Title: Re: Why chmod 777 is NOT a security risk
Post by: Killer Possum on February 09, 2004, 06:04:41 PM
Quote from: Anguz on February 09, 2004, 05:36:30 PM
that's precisely the other host we're talking about (~_^)

Oh, right... guess I should have read those posts a bit more thouroughly
Title: Re: Why chmod 777 is NOT a security risk
Post by: mikeweb on April 10, 2004, 03:34:06 AM
I am trying to understand, basically my YaBB SE site was fine with permissions 755 and I was able to do everything, but SMF needs to be 777 or I am limited on doing things?  Why have that change?  I think most hosts don't let you change to 777 and shut sites down for that.... and not everyone has the cash to host themselves.
Title: Re: Why chmod 777 is NOT a security risk
Post by: [Unknown] on April 10, 2004, 03:50:24 AM
If 755 works for you, that is fine.  But on some hosts you need 777.

-[Unknown]
Title: Re: Why chmod 777 is NOT a security risk
Post by: [Unknown] on April 12, 2005, 11:02:24 AM
More information on the above question:

http://www.simplemachines.org/community/index.php?topic=32991.msg246205#msg246205

-[Unknown]
Title: Re: Why chmod 777 is NOT a security risk
Post by: permutations on July 24, 2005, 02:05:13 PM
Quote from: [Unknown] on November 20, 2003, 03:41:19 AM
Any other questions? (so far I made all these up, sorry if they aren't realistic :P.)  Feel free to ask and I'll answer away.  I challenge you to prove me wrong.... show me that somehow 777 is all that bad.

I'm not a hacker so I can't argue the technicalities of how 777 would give a hacker access. I can tell you, though, that a hacker DID get access to my site when my directories were 777. When my Web host installed suexec so all the permissions could be changed to 775, that shut out the hacker.
Title: PLEASE FOLLOW THE ADVICE OF YOUR BRAIN NOT YOUR VENDOR!
Post by: keepr on August 20, 2005, 02:51:13 PM
This is absolutely ridiculous, There is no good reason for anyone to be setting the whole directory for an application that has read/write access to MySQL to 777. If you need to set a specific file to 777 in order to make settings changes that is fine but allowing every single file in SMF to be RWX x Everyone is just plain asking for trouble...

First off SMF is not bug free and neither is any popular forum software, by setting the whole directory to 777 you are opening up every possible avenue for a software exploitation.

If you cannot make your mods / application work with proper security restrictions then you need to take another look at your code. This post is reckless and potentially damaging to people who do not understand what it means to have their website exploited.

This is like saying My Ferrari has really good door locks so it's ok to leave it in a shopping mall garage overnight without the aid of an alarm.. Oh yeah and let me leave the keys and address's to all my other expensive cars in the glove box while I am at it!

Come on get with the program and help people fix this issue instead of stepping around it..


OOOh I came up with a better analogy, Say you buy a car alarm and then you go buy this really cool Add on that pages you when your alarm goes off..

Well you install it and it's not working so you call the vendor and they say Oh yeah well that model doesn't transmit so well through glass or metal so what you need to do is roll down all your windows and open all the doors when you want to use it! It's OK everything should be fine give it a shot!

2 days later:
You car has been vandalized or is completely missing...
Title: Re: Why chmod 777 is NOT a security risk
Post by: penmin on August 20, 2005, 04:17:15 PM
  - I believe you, but my host doesn't.  They don't want me to make everything 777, they say it's not safe.
So have them read this.  If they can't refute it, prove it wrong, or at least even challenge it then I guess they have to let you do 777 Grin.



I think my host just told you that its not possible w/o a major security risk. So I wont be using TP until someone can fix this.
And btw, it kinda makes me feel abit unsecure that the SMF lead devl. is telling everyone to go unsecure all their ****** (no offense Bloc, Im sure your reading this and TP is quite lovely) but I have to agree (finally) that my host is right, and w/o a secure way to do this, its just something that makes you sit in the waiting room to get hacked.

PS. Unknown, my host could talk and talk for hours about this and argue with you, but we all know he is right. Fix your stuff. :(
Title: Re: Why chmod 777 is NOT a security risk
Post by: kegobeer on August 20, 2005, 05:17:28 PM
If I set my directory to 777, and you navigate to my site, exactly what could you do to gain access to my files?  To my understanding, a file has to be uploaded to the site and then be executed to take advantage of 777.  If a user can't upload any sort of attachments, what damage can be done?
Title: Re: Why chmod 777 is NOT a security risk
Post by: Thunderace on August 20, 2005, 05:26:50 PM
Quote from: penmin on August 20, 2005, 04:17:15 PM
PS. Unknown, my host could talk and talk for hours about this and argue with you, but we all know he is right. Fix your stuff. :(

Very rude imo, [unknown] is well admired for his skills as well as the time he puts into this project. I don't believe your host read his original comment at all and if he did he must have misunderstood its meaning.

I for one find your comments unvalid and rude.
Title: Re: PLEASE FOLLOW THE ADVICE OF YOUR BRAIN NOT YOUR VENDOR!
Post by: [Unknown] on August 20, 2005, 05:28:23 PM
Quote from: keepr on August 20, 2005, 02:51:13 PM
First off SMF is not bug free and neither is any popular forum software, by setting the whole directory to 777 you are opening up every possible avenue for a software exploitation.

If your server is properly secured, that is not true.  Because /home/username (as I've said multiple times) will be owned by username:apache and 750, the last 7 in the 777 only means "apache" not "world".  You could also use PHP suExec, if you do not like that situation, which would allow the avoidance of open_basedir.

QuoteIf you cannot make your mods / application work with proper security restrictions then you need to take another look at your code. This post is reckless and potentially damaging to people who do not understand what it means to have their website exploited.

Clearly, you do not understand the issue or the post.  For example, if attachments is not 777, you cannot post.  If Settings.php is not 777, you cannot change your settings.  These situations are, at times, perfectly fine - but note that these are always readable.  If your server is not properly secured so that the 777 *won't be an issue anyway*, then anyone can read your password easily.  That's the point.

If you do not understand that, I'm willing to guess that your server or servers are not properly secured against such attacks (unless you do not offer shared hosting at all.)

Your analogies are all flawed, since you should have your car parked in a secure garage no one can get into.  It's more like a window.  Windows can be broken, just use a heavy object of some sort.  If you think a window is sufficient protection against someone getting in, you're wrong.  So, you have to be able to live with not putting a metal grate over your windows, because then you'd lose a lot of the use of car windows.... like visibility.

But that's not even a good analogy, because cars do not apply well to hosting.  Why is it that bad hosts always think of themselves as car salesmen?

SMF does not, indeed, need everything to be 777.  But, it really shouldn't matter.  Look at it this way... you have a sign on your car (because you like cars) that tells people what your credit card number and expiration date are.  It's even neon.  You can't take it off - every car has this sign on it.  So, you hide your car in a secured garage (where every parking space is sectioned off and separately locked, only the janitor can get to each room and he is will payed to feign blindness.)  Whether or not you lock your doors doesn't much matter at this point.

However, it's true - might as well lock them, right?  Well, let's say that there's a reason for that neon sign.  Let's say that, every day, the car has to be taken out of that room to a nearby (in the same garage even) scanning station (think of this as attachments.)  Why?  Because you like cars and I'm trying to apply it there for you.  Anyway, this is actually the janitor's main job.  He could bother you, every time this needs to be done, to unlock the car (just as you, if you were an idiot, could make the attachments directory writable every time someone posted an attachment) but this is obviously less-than necessary.  The room the car is in should be locked and guarded (you PAY for that, don't you?!) so leaving the keys with the janitor or leaving the car unlocked shouldn't really matter.

Again, ideally, it wouldn't be necessary.  But these times of credit-card-neon-signs-on-cars-scanning we live in dictate otherwise.  Silly people wanting to post attachments.  As for other things that should be writable, they are also convenience.  Clearly less important than attachments, at least in this example, but important nonetheless.

I don't actually recommend anyone make all their files 777.  I only said that in this topic because the point is, it shouldn't matter if your host is worth any more than $2 a month.  In reality, a mnimum of files can be kept writable.

For more information on these concepts, please look into open_basedir (the janitor), file ownership and permissions on Linux (like how the permissions on the parent are checked before the child), and file access.

Quote from: penmin on August 20, 2005, 04:17:15 PM
I think my host just told you that its not possible w/o a major security risk. So I wont be using TP until someone can fix this.
And btw, it kinda makes me feel abit unsecure that the SMF lead devl. is telling everyone to go unsecure all their ****** (no offense Bloc, Im sure your reading this and TP is quite lovely) but I have to agree (finally) that my host is right, and w/o a secure way to do this, its just something that makes you sit in the waiting room to get hacked.

No, I would suggest avoiding this host.  He doesn't seem to understand or care about securing his servers properly.  If you are on anything but dedicated hosting with him, I strongly suggest going to another - secured - host.

And, please do not pm me about a post.  That is considered very rude.  I responded no faster than I would have otherwise.

Quote from: kegobeer on August 20, 2005, 05:17:28 PM
If I set my directory to 777, and you navigate to my site, exactly what could you do to gain access to my files?  To my understanding, a file has to be uploaded to the site and then be executed to take advantage of 777.  If a user can't upload any sort of attachments, what damage can be done?

Nothing.  777 doesn't give users any access whatsoever.  However, if something is exploited on the server, the following things are possible:
  - the script could get in as root, and you're done.  Go get your backups.
  - the script could run as a user, such as "mysql" or just "exim" and you're going to have fun too.
  - the script could run as Apache (which almost always means that's how it got in) and then you have protections like open_basedir (on half-decent hosts.)

In any case, a large number of files are going to go down the sink.  If the server is properly configured, there will only be three users with access to /home/username: apache (usually "nobody"), username, and root.  Of these, apache/nobody would be the best secured.  But only, of course, when the host knows what he or she is doing.

-[Unknown]
Title: Re: Why chmod 777 is NOT a security risk
Post by: keepr on August 20, 2005, 09:43:46 PM
I simply cannot believe your blatant ignorance of the security issues you are advising people to open themselves up to.

My comment is strictly in reference to chmod-r 777 smf/

Making the attachments directory rwx is common practice and perfectly acceptable.

You are asking people to bypass linux's built in security and trust that all your code is perfect and no exploits will ever be found in it (this is scarey considering that SMF is YABB with a new name) and since your telling my customers to find new hosting I will point out examples of why people should use every piece of security possible with SMF specifically. I really wish you had not made this personal but here we go.

Examples of past SMF-YABB exploits:

Smf Size Tag Script Injection Vulnerability
http://www.governmentsecurity.org/archive/t8454.html

Simple Machine Forum SQL Injection (modify)
http://www.securiteam.com/exploits/5HP0N0KG0O.html

Yabbse 1.5.4 Sql Injection Poc Exploit
http://www.governmentsecurity.org/archive/t6065.html

YaBB/YaBBse Cross Site Scripting Vulnerability
http://seclists.org/lists/bugtraq/2004/Mar/0135.html

Yabase v1.5.0 remote exploit to spawn bash shell with Apache uid
http://www.remoteassessment.com/darchive/191005567.html

YabbSE Multiple Vulnerabilities March 2004
http://www.net-security.org/vuln.php?id=3305

There are many more exploits and people can look them up themselves at:

Results 1 - 10 of about 18,400 for smf;exploit
http://www.google.com/search?sourceid=navclient&ie=UTF-8&rls=GGLD,GGLD:2005-15,GGLD:en&q=smf%3Bexploit

Your welcome to voice your opinion of course but I am also welcome to voice mine, Telling peoples customers to go find another host because people cannot get a mod to work is the most childish thing I have ever seen from a software developer.
Title: Re: Why chmod 777 is NOT a security risk
Post by: penmin on August 20, 2005, 09:46:08 PM
First off, I do apologize for being rude, but I am more than abit frustrated, I have tried numerous times to get any type of help with this ONE problem for over a month now. Maybe if you got off your high horse and stopped acting like a 20 year old that knows everything, and instead, work on your bull****** to make it work proper. I wouldnt get all pissy with you. I have tried to contact 4 differant peope (outside of threads) to gain help, and what was I told............ Contact an admin.......so I tried that, and everyone suggested 777 everything during the install (but change back the settings file), then after install, change everything back to normal and continue on your merry way. Then I am told I need to change and 777 everything, but then you dont state anything else. You just go 'challenge me', so I did. And you still have yet to prove how this will work w/o the actual person being taken advantage of and getting all their mysql jacked.

The reason for backups is just in case, for me, just in case I mess up real bad, not just in case I get hacked b/c some 20 yr old admin of a site said 'Okay go do this its ok, cuz I swear by it'. I dont see how this is something that you can call a good thing when it only seems as a easy way out for you.

He did read the entire thread, and I will not be changing my host company. He puts more effort into his work than any of you do with your bs blah blah blah about why this is something so easy to fix. It makes me go and delete my damn smf. It's not worth the space on my server. Cheers folks!
Title: Re: Why chmod 777 is NOT a security risk
Post by: tentronik on August 20, 2005, 10:15:02 PM
Hi just like to note that i use SMF since 1.0 beta  and i never ever heard off an real (not user failure) exploited SMF.
And only because he says diffrent is making you angry why you want him to xchange (us all here) the software just for your very special kind of server setup?

Also i like to note that you useing an offensive  ignorant way here i quoted you
QuoteMaybe if you got off your high horse and stopped acting like a 20 year old that knows everything, and instead, work on your bull****** to make it work proper

Chill, relax make it 777 - fine if you got mad haxxored then you can come here again and brag about your ownage whtever.

@ Keepr
You posted 2 out of date sql injections - i think 2 security issues are not much for an beta(v 1.04 and 1.05 ). If you use phpBB you will encounter much more flaws!

e.g. phpbb exploit at google  (http://www.google.com/search?hl=de&rls=GGLD%2CGGLD%3A2005-15%2CGGLD%3Aen&q=phpbb%3Bexploit&btnG=Suche&lr=) over 400k.
or
vBulletin at google  (http://www.google.com/search?hl=eng&q=vBulletin%3Bexploit&btnG=Suche&meta=)over 158k
or
SMF exploit  google (http://www.google.com/search?sourceid=navclient&ie=UTF-8&rls=GGLD,GGLD:2005-15,GGLD:en&q=smf%3Bexploit) 18k

Also the question is are these injections caused by the chmod of folders or not.

Title: Re: Why chmod 777 is NOT a security risk
Post by: IchBin™ on August 20, 2005, 11:24:39 PM
Yabb is written in CGI/Perl, a whole different animal.  SMF is not anything like Yabb. It's a complete rewrite if you ask me.....
Title: Re: Why chmod 777 is NOT a security risk
Post by: [Unknown] on August 20, 2005, 11:34:40 PM
Quote from: keepr on August 20, 2005, 09:43:46 PM
You are asking people to bypass linux's built in security and trust that all your code is perfect and no exploits will ever be found in it (this is scarey considering that SMF is YABB with a new name) and since your telling my customers to find new hosting I will point out examples of why people should use every piece of security possible with SMF specifically. I really wish you had not made this personal but here we go.

No, I am not.  I am asking people to take advantage of Linux security to keep themselves secure.  You do not seem to understand it.

If a hole allows people to write to files, it is almost always the case that it also gives read access to files.  For example, most execution holes allow the use of cat, wget, etc.

If you can cat, you can cat Settings.php.  If you can cat Settings.php (which Apache must be able to do) you have the MySQL database password.  If you have the MySQL database password, the game is up.  Making files writable or not won't help anyone, because the darn files *never change.*  Once someone has the access to change a file, changing the files helps them no more than the access they already have.

This is a crucial point you do not seem to understand.

QuoteSmf Size Tag Script Injection Vulnerability

This was in a beta version, and provides no access to the server.

QuoteSimple Machine Forum SQL Injection (modify)

This provides no access to the server.

QuoteYabbse 1.5.4 Sql Injection Poc Exploit
YaBB/YaBBse Cross Site Scripting Vulnerability
YabbSE Multiple Vulnerabilities March 2004

This is a long time ago.  When this code was developed, I was not involved in YaBB SE.  Neither was Grudge.  Neither were a lot of people.  The fact that you think YaBB SE and SMF are at all similar in the code they use shows me you know nothing about PHP at all, which isn't surprising.

But, again the above did not give any access to the server.  777 was not a problem.

QuoteYabase v1.5.0 remote exploit to spawn bash shell with Apache uid

This one did allow remote access.  Using this (which was similar to phpBB's recent highlight hole) you could do anything.  It was bad.  Again, I was not involved at the time this code was developed, but having files 777 or 700 wouldn't have made this any different.  Worse things happened, and in most cases - with this security hole - it wasn't the 777 things that were touched.

Quote
http://www.google.com/search?sourceid=navclient&ie=UTF-8&rls=GGLD,GGLD:2005-15,GGLD:en&q=smf%3Bexploit

99% of those results have nothing to do with SMF.

I am warning against the use or your hosting services because the arguments you are making are not only less-than professional, but they also evidence lack of knowledge about the entire situation.  I would never host with someone who did not understand certain key and important parts of Linux, Apache, PHP, and MySQL security; nor would I recommend anyone host with such a person.

Quote from: penmin on August 20, 2005, 09:46:08 PM
First off, I do apologize for being rude, but I am more than abit frustrated, I have tried numerous times to get any type of help with this ONE problem for over a month now. Maybe if you got off your high horse and stopped acting like a 20 year old that knows everything, and instead, work on your bull****** to make it work proper. I wouldnt get all pissy with you. I have tried to contact 4 differant peope (outside of threads) to gain help, and what was I told............ Contact an admin.......so I tried that, and everyone suggested 777 everything during the install (but change back the settings file), then after install, change everything back to normal and continue on your merry way. Then I am told I need to change and 777 everything, but then you dont state anything else. You just go 'challenge me', so I did. And you still have yet to prove how this will work w/o the actual person being taken advantage of and getting all their mysql jacked.

You've posted twice about a problem with Tinyportal.  This problem is caused by Tinyportal trying to add an image for its use.  If you cannot or are not willing to make your files writable, even temporarily, for said image to be automatically installed for you, you are welcome to install it manually - even though that can be difficult and time consuming.  However, it really doesn't look to me like you tried very hard.

You are also quick to go back to rudeness after apologizing.  If you cannot accept that a person of my age might know something, you're in the wrong line of work.  Go work on your cars, because when it comes to computers you're going to be dealing with younger people.  I am not the one swearing, you are the one acting juvenile.

I do not know everything, nor do I act like I do.  I have never done, nor do I have any experience when it comes to, lion taming.  However, I have spent more than half of my life working with computers.  I have worked for UCLA, I have worked for various schools when I was younger.  When it comes to computers - at least certain parts of them - I do know something.  I don't know what you do, and I'm sure you know what you're talking about it when it comes to... whatever that is.

I have already proved it, and with multiple examples.  If you refuse to believe me, you're not going to believe me.... so why should I waste my time anymore?

Quote
He did read the entire thread, and I will not be changing my host company. He puts more effort into his work than any of you do with your bs blah blah blah about why this is something so easy to fix. It makes me go and delete my damn smf. It's not worth the space on my server. Cheers folks!

Best keep on with those backups, then.

-[Unknown]
Title: Re: Why chmod 777 is NOT a security risk
Post by: Amacythe on August 20, 2005, 11:39:29 PM
One thing I'd like to point out is that any good debate is strongly supported by both sides and the subject of the debate is kept as the item of discussion.  When one of the people involved in the debate turns the topic of discussion to personal insults, that person shows that they can no longer defend their stance and that they have (in their own mind) already lost the debate.  I see no where that [Unknown] has attacked anyone, yet somewhere along the lines penmin has seen fit to make comments that are out of context here:

QuoteMaybe if you got off your high horse and stopped acting like a 20 year old that knows everything, and instead, work on your bull****** to make it work proper. I wouldnt get all pissy with you.

It really is a shame.  I'd like to hear more about why I shouldn't trust my host to keep my files secure.
Title: Re: Why chmod 777 is NOT a security risk
Post by: Valodim on August 20, 2005, 11:40:22 PM
there is one easy reason for why not all files should be chmodded 777:

a hacker is not always only destructive.

for example, if he once gets access, he can just modify an existing php file, so he can send system() or eval() or mysql_query() calls, or only become secret administrator on the forum by adding || $ID_MEMBER == 1234 for the is_admin in the load.php. once the security hole he got in through is fixed (chances are, it will get fixed sooner or later), he keeps his access to all private sections of your forum, or files, or whatever you might have on your server.
Title: Re: Why chmod 777 is NOT a security risk
Post by: [Unknown] on August 20, 2005, 11:50:58 PM
Quote from: Valodim on August 20, 2005, 11:40:22 PM
there is one easy reason for why not all files should be chmodded 777:

a hacker is not always only destructive.

for example, if he once gets access, he can just modify an existing php file, so he can send system() or eval() or mysql_query() calls, or only become secret administrator on the forum by adding || $ID_MEMBER == 1234 for the is_admin in the load.php. once the security hole he got in through is fixed (chances are, it will get fixed sooner or later), he keeps his access to all private sections of your forum, or files, or whatever you might have on your server.

If I had that sort of access to a server, and for some reason wanted to hack it (perhaps because I was being paid to audit and prove security holes) I would put a new file in attachments.  This would not be the first place anyone would look, and would work on almost every installation.  Without not using attachments at all, you couldn't protect against this.

So, avoiding making some files writable really doesn't help you.  You have to have some files writable, and that will always be a problem.

However, it's true that if you have any reason to believe a server was hacked, you need to clean out everything.  For example, phpBB's server was once hacked and they were down for quite some time afterward because they redid everything on their server from scratch.  As bad a record as they may have for security, this was really the smart thing to do and speaks against their reputation.

And it's not just files, either.  A hacker could plant a privileged user on the forum who could, a month later, become a huge problem.

-[Unknown]
Title: Re: Why chmod 777 is NOT a security risk
Post by: Valodim on August 20, 2005, 11:57:05 PM
.htaccess in attachments:
<Files *.php>
disallow from all
</Files>

*bang*

a temporary files folder can just not have any executable file types allowed in it, that's it. It is indeed possible to not have any writable executable files on the server, which are a major security risk for long-term hacks. plus there's no reason to have everything 777-chmod'd

Quote
And it's not just files, either.  A hacker could plant a privileged user on the forum who could, a month later, become a huge problem.

bah, it's easy to find a privileged user in the database (check membergroups, check members, check per-member-permissions if available, done), but there are tons of possibilities to hide a privilege escalation code in a php file...
Title: Re: Why chmod 777 is NOT a security risk
Post by: keepr on August 20, 2005, 11:58:53 PM
Amacythe brings up a good point and if this got personal please excuse me for pushing a bit harder than I normally would on the issue..

Basic Linux best practices dictate that public files on your web server should not be rwx because almost any exploit becomes much much worse in this situation, Furthermore I don't understand why the specific files that need to be tagged 777 cannot be disclosed rather than taking a sloppy approach and applying rwx access to an entire forum installation.

I guess the point is that nobody knows what exploit is going to come out tomorrow, So why tell people to make their forum installations even more unsecure than "ANY" forum software already is. All forum software gets exploited sooner or later it seems to me that due to this history the last thing you would want anyone to do is open all their files to an attack.

Another good reason to make all your files are secured is that anyone who gets into the account be it via injection, exploit or whatever would be able to add arbitrary code to your installation like a call to a virus stored offsite. This happened a while back at a large webhosting provider in ATL. Basically someone compromised the server and wrote 1 line of code to all the php / html files in the users directories (the ones chmoded 777 anyway) that when executed pulled a virus to the end users computer from a 3rd party website. Anyone visiting a webpage on an infected server was subjected to arbitrary virii code. This did not happen on sites that maintained a strict file security policy.

The server penmin was having trouble on is a Standards compliant Cpanel server, the exact same setup as 10's of thousands of other hosting providers.
Title: Re: Why chmod 777 is NOT a security risk
Post by: [Unknown] on August 21, 2005, 12:32:05 AM
Quote from: Valodim on August 20, 2005, 11:57:05 PM
a temporary files folder can just not have any executable file types allowed in it, that's it. It is indeed possible to not have any writable executable files on the server, which are a major security risk for long-term hacks. plus there's no reason to have everything 777-chmod'd

Not quite.  You're ignoring py files, phtml, php3, php4, pl, cgi, and lots of other files which *may* (on some servers) also be a problem.

I never said you should have everything 777.  But, it's not really that much worse than not.  If you're having big problems, installing things or whatever, the world won't end if you make your files 777.  You're going to have to redo everything either way.

Quotebah, it's easy to find a privileged user in the database (check membergroups, check members, check per-member-permissions if available, done), but there are tons of possibilities to hide a privilege escalation code in a php file...

Not always.  You're also ignoring things like crons.  What if I added this to your crontab?

php -f ~/public_html/forum/attachments/something_that_looks_innocent.doc

Quote from: keepr on August 20, 2005, 11:58:53 PM
Basic Linux best practices dictate that public files on your web server should not be rwx because almost any exploit becomes much much worse in this situation, Furthermore I don't understand why the specific files that need to be tagged 777 cannot be disclosed rather than taking a sloppy approach and applying rwx access to an entire forum installation.

They are.  This topic is not about SMF as much as it is general.  For information specific to SMF, please look elsewhere - an exact list is, indeed, specified.

QuoteAnother good reason to make all your files are secured is that anyone who gets into the account be it via injection, exploit or whatever would be able to add arbitrary code to your installation like a call to a virus stored offsite.

An injection hole cannot give system-level or file access, without the use of LOAD DATA INFILE, which doesn't really count because that's only reading files.

As for viruses, /tmp will always be writable (even though some hosts have made it not, causing MySQL to crash and/or not work), and that's how most hacks and viruses involving file access are introduced.  Said file is then run from there with perl (usually perl) and from there, it could easily harvest database passwords (since perl won't be limited) and nuke everyone's databases.  This is why chrooting is so popular.

Another method would be to create large random files in the attachments, /tmp, and other directories - effectively filling the partitions and making it very difficult to undo (you can't rm * if there are too many files, and most FTP clients cannot handle huge directories.)  MySQL, in such a sitation, will give strange error messages and may even crash.

In an ideal situation, Apache 2 and perchild would both be stable, and you would have /home/username owned by username:username-www or similar.  This would limit any security problems to their directory (and /tmp) but currently the next-best alternative is PHP suExec.

QuoteThe server penmin was having trouble on is a Standards compliant Cpanel server, the exact same setup as 10's of thousands of other hosting providers.

Using Cpanel doesn't automatically make you secure.  Most Cpanel servers are misconfigured in many ways, for one they do not use open_basedir most of the time.  It's a good, standard, one size fits all... but that doesn't mean it's a picture of perfection.

Note, however, that I - like many - have a high opinion of Cpanel and its efforts to make server management easier.

-[Unknown]
Title: Re: Why chmod 777 is NOT a security risk
Post by: Amacythe on August 21, 2005, 12:38:07 AM
I'm still trying not to take sides here, but your comment:
QuoteBasically someone compromised the server and wrote 1 line of code to all the php / html files in the users directories (the ones chmoded 777 anyway) that when executed pulled a virus to the end users computer from a 3rd party website. Anyone visiting a webpage on an infected server was subjected to arbitrary virii code. This did not happen on sites that maintained a strict file security policy.
makes me wonder if this whole thing is merely a matter of a server owner not wanting the responsibility of security that should be his by default. 
Title: Re: Why chmod 777 is NOT a security risk
Post by: [Unknown] on August 21, 2005, 12:40:32 AM
Forgive me for making a second post, but I think I saw where the confusion lies.

The main reason you would want all of your files writable is simple.  As we have been arguing about, PHP cannot write to files which are not writable.  So far, we're on the same page... except you think that's something you want.

It isn't.  If files are writable, or I make them writable, I can upgrade a forum (which is, let's say, insecure and vulnerable to one of the holes you noted, just as an example) within 10 seconds.  Less, really.  This is because the PHP code will do the updating for me, patching the security hole automatically - all I have to do is click "Proceed".

When updates are easy, as you may know from Cpanel, they are more likely to be done.  So, I ask, which is more important?

Would you rather make the forum insecure for longer, only able to damage other sites on the server... or would you rather make it easy and simple to update?  There's no way around it.... if there's a security hole in the code, the code has to change.  If you want PHP to do it for you (which can save you an hour of work), you'll have to give it permission.

This is the point of this topic.  This topic is about the package manager, and automatic updates.  That is the implicit "what you're getting in return".

-[Unknown]
Title: Re: Why chmod 777 is NOT a security risk
Post by: keepr on August 21, 2005, 01:28:37 AM
Quote from: Amacythe on August 21, 2005, 12:38:07 AM
I'm still trying not to take sides here, but your comment:
QuoteBasically someone compromised the server and wrote 1 line of code to all the php / html files in the users directories (the ones chmoded 777 anyway) that when executed pulled a virus to the end users computer from a 3rd party website. Anyone visiting a webpage on an infected server was subjected to arbitrary virii code. This did not happen on sites that maintained a strict file security policy.
makes me wonder if this whole thing is merely a matter of a server owner not wanting the responsibility of security that should be his by default. 

Actually the hosting company I was referring to is Interland.

No matter how much you secure a server end users are the endall to security.

For instance:
A huge portion of spyware / adware is installed by end users because they want fancy desktop backgrounds of screensavers and click on ads to install them, This is not microsoft's fault, This is not Dell's fault, The fault lies in the end user.

No matter how secure you make your server any users with an account on the server can open "themselves" up to an exploit. No comment I ever made had anything to do with the overall security of the server, I was simply concerned about the security issues on the end users account. The suggestion that the end user in this case should not chmod -R 777 smf/ was for their benefit not the hosting company.

It does not matter how secure a server is, If a user has a script on it that is exploitable that account can be and most likely will be exploited.

Another point that people might be interested in is that files with a permission setting of 777 can be deleted by any user / application.
Title: Re: Why chmod 777 is NOT a security risk
Post by: [Unknown] on August 21, 2005, 01:33:44 AM
Quote from: keepr on August 21, 2005, 01:28:37 AM
Actually the hosting company I was referring to is Interland.

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

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

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

-[Unknown]
Title: Re: Why chmod 777 is NOT a security risk
Post by: [Unknown] 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:
Title: Re: Why chmod 777 is NOT a security risk
Post by: tentronik 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
Title: Re: Why chmod 777 is NOT a security risk
Post by: [Unknown] on August 23, 2005, 01:05:05 AM
Quote from: tentronik 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.

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

The very same with Mambo.

QuoteAnd 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.

QuoteAnd 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]
Title: Re: Why chmod 777 is NOT a security risk
Post by: Orstio on August 24, 2005, 09:09:32 PM
QuoteBut 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.
Title: Re: Why chmod 777 is NOT a security risk
Post by: Joshua Dickerson 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.
Title: Re: Why chmod 777 is NOT a security risk
Post by: raymor 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:
<?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.

Title: Re: Why chmod 777 is NOT a security risk
Post by: tentronik 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?
QuoteIf 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
Title: Re: Why chmod 777 is NOT a security risk
Post by: carlatf 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
Title: Re: Why chmod 777 is NOT a security risk
Post by: dtm.exe on December 27, 2005, 10:19:57 AM
Quote from: carlatf 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


Please include a link to your forum as well as a test account's login details.
Title: Re: Why chmod 777 is NOT a security risk
Post by: Anguz 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.
Title: Re: Why chmod 777 is NOT a security risk
Post by: alchemy on December 27, 2005, 09:52:28 PM
Quote from: David on November 20, 2003, 03:48:49 AM

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/[email protected]
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.
Title: Re: Why chmod 777 is NOT a security risk
Post by: higherauthority 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://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


Title: Re: Why chmod 777 is NOT a security risk
Post by: kegobeer on February 14, 2006, 08:43:54 PM
CHMOD is not applicable to Windows operating systems.  This is a *nix command.
Title: Re: Why chmod 777 is NOT a security risk
Post by: higherauthority 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?
Title: Re: Why chmod 777 is NOT a security risk
Post by: sm2k 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. 
Title: Re: Why chmod 777 is NOT a security risk
Post by: alchemy 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.

Title: Re: Why chmod 777 is NOT a security risk
Post by: Anguz 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.
Title: Re: Why chmod 777 is NOT a security risk
Post by: Amacythe on February 15, 2006, 08:34:07 PM
My host doesn't allow 777 and all my files are 755
Title: Re: Why chmod 777 is NOT a security risk
Post by: duminas 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. ^^
Title: Re: Why chmod 777 is NOT a security risk
Post by: sm2k on February 16, 2006, 05:54:50 PM
777 is easier from the website admin side.  It suddenly becomes trivial to perform neat tricks like automated package/mod installations, style sheet editing from the admin panel, file uploads, etc.

I agree though, file permissions are the basis of any security system, and should be as tight as possible.  There are methods for providing the same services that we already enjoy without leaving directories wide open.  Yes, it is most certainly possible that a hacker could still manipulate the system, and yes it is possible that he/she could then reset file permissions depending on the vulerability and system config.  That doesn't make file permissions any less important.

Really, why have any security in the file system at all?  Just leave it wide open and trust each and every software developer...right?  Besides, if a hacker can get root permissions then he can do whatever he wants anyhow...right?  ;)
Title: Re: Why chmod 777 is NOT a security risk
Post by: alchemy on February 17, 2006, 06:09:12 PM
Quote from: Anguz 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.

My installation differs from most, because I move Settings*, Sources/  and the temp directories, for SMF, to a path not readable by apache.  (this requires a bit of editing, too much to explain)

I prefer security over simplicity. If you do permissions similar to this, you will probably have to upgrade your forum manually. Note: The respective UID's and GID's of SMF, apache, and SMF Group may differ on your server.

For the most part, this gives the "least possible permissions", and it works with PHP "Safe Mode", PHP hardening, chrooted apache, and other restrictions too numerous to list.


#SMF CUSTOM INSTALLATION
chown -R smf.web /chroot/forums/
chown -R smf.web /chroot/scripts/forums/
find /chroot/forums/ -type f | xargs chmod 644
find /chroot/forums/ -type d | xargs chmod 755
find /chroot/scripts/forums/ -type f | xargs chmod 644
find /chroot/scripts/forums/ -type d | xargs chmod 755

chown smf.apache /chroot/forums/attachments/
chmod 775 /chroot/forums/attachments/
chown apache.apache /chroot/forums/attachments/*
chown smf.web /chroot/forums/attachments/index.php
#chown root.root /chroot/forums/SSI.php <- disabled for now

chown apache.web /chroot/scripts/forums/tmp_{ssp,upload}/
chown apache.apache /chroot/scripts/forums/tmp_ssp/*
chmod 600 /chroot/scripts/forums/tmp_ssp/*
chown smf.apache /chroot/scripts/forums/Settings*
chmod 660 /chroot/scripts/forums/Settings*


httpd.conf

<Directory "/chroot/scripts">
    Options None
    AllowOverride None
    Order Allow,Deny
    Deny from all
</Directory>

<Directory "/chroot/forums">
        blablabla...other directives
        php_admin_value include_path  ".:/chroot/scripts/forums"
        php_admin_value session.save_path "/chroot/scripts/forums/tmp_ssp"
        php_admin_value upload_tmp_dir "/chroot/scripts/forums/tmp_upload"
</Directory>


Title: Re: Why chmod 777 is NOT a security risk
Post by: Prasad007 on May 09, 2006, 03:11:19 PM
hey wow! Thanks for the gr8 article unknown :)
Title: Re: Why chmod 777 is NOT a security risk
Post by: sawz on June 15, 2006, 06:59:55 AM
that was a long thread, and interesting...
Title: Re: Why chmod 777 is NOT a security risk
Post by: StupidScript on June 23, 2006, 11:58:39 PM
World-writeable directories are ALWAYS a BAD idea.

Do I really need to say anymore? I know that many posters have asked for proof that these are dangerous, however to do so would be to provide ammunition to script-kiddies who are seeking easy-to-exploit flaws in the programming.

This thread seems to be focused on CHANGES on the directory owners, but that's not the point of security.

I remember, a few years ago, when our corporate intranet servers were compromised by a warez/script distributor. They set up directories on our servers that contained games, porn movies, copyright-infringing applications and more. And you know, they didn't even have root! They didn't care.

Why? Because they could WRITE to the directories.

For example: I really don't care if you want me to be able to EXECUTE scripts .. all I want is to be able to tell my customers, "Go to http://SOM.IPA.DDR.ESS/warez and download GTA for free!"

World-writeable = bad. Talk about the odds as much as you want. With armies of zombie networks available to perform stuff that you have no idea could even happen ... your server is at EXTREME risk when ANY directory is world-writeable. Let's talk about escalation of privileges ...

Go ahead ... DEMAND proof ... I really don't care. I've got your/my server. Bye. (Oh, by the way, you can't send email from that server because it has been blacklisted ... haha.)

Now let's hear some justification that explains THAT to your multi-millionaire boss. Or maybe you don't have a multi-millionaire boss .. and you probably never will. Fair warning.
Title: Re: Why chmod 777 is NOT a security risk
Post by: Harzem on June 24, 2006, 07:52:38 AM
Since you are unable to protect your servers, it is expected you not to love 777. This is why 777 isn't a security risk.
Title: Re: Why chmod 777 is NOT a security risk
Post by: forumposters on August 10, 2006, 02:23:05 AM
Is there an easy one step way within cpanel to chmod all the directories and files from 777 to 755 and 644?  Or, do you need shell access?
Title: Re: Why chmod 777 is NOT a security risk
Post by: ccondrup on August 23, 2006, 02:14:14 PM
I am renting a normal account on a shared server. I have all files chmod 644 and folders 755 for my SMF-forum. This works fine - uploads, packages, attachements, avatars etc. How? My host is running suPHP. That means Apache runs as my own (linux/ftp) user, via the suPHP module. When you upload a file through php, the file will be owned by your ftp user, instead of httpd, www or nobody. On this host with suPHP, php-scripts will not even run if chmod 777.

phpsuexec was mentioned in this thread, I think cPanel supports and maintains this version for their commercial cPanel customers, but the project it self has stagnated some time ago.

suPHP (http://www.suphp.org/Home.html) on the other hand, seems to be an ongoing active project. Here is a guide on how to get the magic working (http://pookey.co.uk/wiki/php/suphp)
Title: Re: Why chmod 777 is NOT a security risk
Post by: TANDIONO.COM on August 23, 2006, 04:24:28 PM
try 755 if 777 fail  ;)
Title: Re: Why chmod 777 is NOT a security risk
Post by: Atticka on September 03, 2006, 04:02:54 PM
Ok, my first post here and its gonna be in this hot topic, lol.

Unkown or anyone, would it be possible to get the following info?
What folders require 777 for SMF operate properly (Attachments? source?)
What folders can stay 755 with losing features (smiley folder doesnt need 777 does it?)

What should be the default permissions on files?

Regardless of host, server setup, etc....its always a good idea to set appropriate permissions on folders and files.
Title: Re: Why chmod 777 is NOT a security risk
Post by: Harzem on September 03, 2006, 04:07:06 PM
Quote from: Atticka on September 03, 2006, 04:02:54 PM
Ok, my first post here and its gonna be in this hot topic, lol.

Unkown or anyone, would it be possible to get the following info?
What folders require 777 for SMF operate properly (Attachments? source?)
What folders can stay 755 with losing features (smiley folder doesnt need 777 does it?)

What should be the default permissions on files?

Regardless of host, server setup, etc....its always a good idea to set appropriate permissions on folders and files.

I always use 755 for directories and 644 for files. This also depends on the server, for example suEXEC setting of apache. But you can still try this and have a look :)
Title: Re: Why chmod 777 is NOT a security risk
Post by: Atticka on September 03, 2006, 04:13:26 PM
Quote from: HarzeM on September 03, 2006, 04:07:06 PM
I always use 755 for directories and 644 for files. This also depends on the server, for example suEXEC setting of apache. But you can still try this and have a look :)

Ok, this doesnt help....becuase if I go 755 on the attachment folder....I cant upload attachments anymore.

755 on the packages folder breaks the upgrade feature.

God knows what will break if I set 644 on all files!

Just looking for some guidance or what to expect when you start changing permissions without knowing the consequences.
Title: Re: Why chmod 777 is NOT a security risk
Post by: Harzem on September 03, 2006, 04:24:01 PM
Ok, then:

777 for attachments (not avatars).
755 for Packages and other folders. Only when you need to install a mod or upgrade, make packages, sources and themes folders 777 temporarily.
Settings.php should be manually set to 777 when editing server settings. Other times, keep it 644.
Other files should be 644 unless you are installing a mod or upgrade.
Title: Re: Why chmod 777 is NOT a security risk
Post by: hygron on September 08, 2006, 02:41:08 AM
this thread blows me away.  I have been struggling to understand the whole permissions query, but why as well...[unknown] great job of explaining and defense...got thru about 3-4 pages.  It just clicked...probably will come back for a few more pages, but right now I am going to chmod777 a few files that haven't been changed.  this mioght solve a install.php problem I have been having all day...no tables in Database.  thanks for the great info and explanation's
Title: Re: Why chmod 777 is NOT a security risk
Post by: TwinsX2Dad on October 07, 2006, 12:45:15 AM
It really is pretty simple gang - and unknown has it right from the start. Plainly put, the 777 gives global permissions to applications on the system and not to the world. The practice of using chmod on files dates back over 40 years with the original Bell System UNIX servers - without permissions, every bit of software on the server might be able to change every file on the server.

If someone can get into your files, they are already in your system, your server, your folder, your whatever. Once they are there, a simple chmod setting isn't going to stop them - if it were a deterent, they could simply change the permissions.

In most cases, you could apply a chmod of 777 across the board and your files will be no less safe.
Title: Re: Why chmod 777 is NOT a security risk
Post by: geer on November 29, 2006, 12:32:39 PM
HI all

sorry me my english is bad , but my Question is how i change CHMOM so that all  files was good.



Thanks very much
Title: Re: Why chmod 777 is NOT a security risk
Post by: IchBin™ on November 29, 2006, 02:07:07 PM
How do I use chmod? (http://www.simplemachines.org/community/index.php?topic=23690.0)
Title: Re: Why chmod 777 is NOT a security risk
Post by: geer on November 30, 2006, 11:51:22 AM
Quote from: IchBin™ on November 29, 2006, 02:07:07 PM
How do I use chmod? (http://www.simplemachines.org/community/index.php?topic=23690.0)

How I settining all files on  server so that was all good , because me not work  installing news Packages

e.g.  Packages on 777
       soucres on 755
       etc.


thanks yet once

Title: Re: Why chmod 777 is NOT a security risk
Post by: jackregan on May 17, 2007, 02:09:49 PM
Sorry to reactivate an old thread, but there are so many questions in my little head...

Am I right in thinking that the main threat from hackers comes from other customers on the same server, being able to sidestep into your account because it's not jailed??

I sort of understand this because it was like this at my University. We could just ftp our accounts and then go up a level to see everyone elses... a little naughty :)

If I am right, then how can I tell if accounts are jailed on my host??
Title: Re: Why chmod 777 is NOT a security risk
Post by: RustyBarnacle on August 02, 2007, 01:18:04 PM
Well this explains a lot, thanks again to all that posted such great info in here.  Just a little bump for those like me that have spent most of last night and this morning wondering why the world came crashing down, and then it appears that a mod changed some permissions.

I dont know if they can do that or not but I installed some mods, and then several things started screwing up, after much todo I saw that my permissions were all out of whack.
Title: Ynt: Why chmod 777 is NOT a security risk
Post by: Government on December 01, 2007, 11:14:05 AM
nice text.
And i put all files as 777 permission.

But, i want install new package and allways got error that i can`t.

QuoteAn Error Has Occurred!
You cannot download or install new packages because the Packages directory or one of the files in it are not writable!

I can`t belive, i put all in 777 (chmod -R 777 public_html/forum/*) and nothing, same error.
Did i must something else change to can install packages?


Thank you for advice.
Title: Re: Why chmod 777 is NOT a security risk
Post by: IchBin™ on December 01, 2007, 12:29:23 PM
You should read through this thread and try some of the work arounds that have been posted.
http://www.simplemachines.org/community/index.php?topic=28393.0
Title: Re: Why chmod 777 is NOT a security risk
Post by: Government on December 01, 2007, 12:42:34 PM
yeah, sorry.
found it.

didnt make temp dir in Packages.

tnx. for answer.
Title: Re: Why chmod 777 is NOT a security risk
Post by: rtyug on September 28, 2008, 07:03:29 AM
666 is ok :)

catalogues 750
Title: Re: Why chmod 777 is NOT a security risk
Post by: I AM Legend on October 22, 2008, 05:00:56 PM
Hi all,
my forum was just recently hacked, and reading through all of this, I found a post in it about .htaccess file in the attachments, I have just found a .htaccess file in my attachments folder on my host in my public directory is this normal? should I delete it?,
my 1st post on this is located here
http://www.simplemachines.org/community/index.php?topic=269241.0
any help anyone has on this and on the 0777 issue would be great
Thanks all
Title: Re: Why chmod 777 is NOT a security risk
Post by: rickyk586 on December 11, 2008, 03:29:32 AM
If you change the owner of the directory to the same owner of the server, then the server (including PHP) can write to that folder without the need for it to be 777.  However, this will probably make the FTP not work anymore, since now, the only user that can edit the directory is the server.  Anyways, here is how to do that:

1)  make this php script (don't run yet):  mkdir("temp");
2)  place script into a folder (example: "scripts")
3)  change the permissions on this folder ("scripts") to 777 (this is just for now)
4)  run the script
5)  change the permissions on the folder ("scripts") back to what it was (755 maybe)
6)  the server now has the ability to write to the folder.

Since this restricted my FTP access, I did not do it this way.  I decided to make the folder ("temp") 777 and not worry about it since the files it is creating are 755.

As far as I know, even if the folder is 777, this only gives the public the ability to create new files in the folder, it has nothing to do with the files.  PLEASE correct me if I am wrong.
Title: Re: Why chmod 777 is NOT a security risk
Post by: taha116 on December 28, 2008, 11:56:40 PM
Is there no way to protect a database completly? Even if it costs some money?
Title: Re: Why chmod 777 is NOT a security risk
Post by: aldo on December 29, 2008, 02:01:59 AM
You could have a MySQL user only assigned permissions to only read from the database... So no... :P

I mean unless you want your MySQL database to act as a archive you just can't. The only way you can protect it is have a good password so people can't get into your server and have a good MySQL password so they can't get in either
Title: Re: Why chmod 777 is NOT a security risk
Post by: taha116 on December 30, 2008, 12:43:48 PM
Quote from: aldo on December 29, 2008, 02:01:59 AM
You could have a MySQL user only assigned permissions to only read from the database... So no... :P

I mean unless you want your MySQL database to act as a archive you just can't. The only way you can protect it is have a good password so people can't get into your server and have a good MySQL password so they can't get in either

So its just as easy to hack my 1.1.7 site as it would be to hack this SMF community site? I don't believe that, because if people report getting hacked then why dosent some whacko just hack this too? Their are obviously some differences that you have not considered?
Title: Re: Why chmod 777 is NOT a security risk
Post by: Killer Possum on December 30, 2008, 05:31:28 PM
Quote from: taha116 on December 30, 2008, 12:43:48 PM
So its just as easy to hack my 1.1.7 site as it would be to hack this SMF community site? I don't believe that, because if people report getting hacked then why dosent some whacko just hack this too? Their are obviously some differences that you have not considered?

The differences are in the configuration of the server as well. Just because site A gets their forum hacked doesn't mean site B can be hacked in the same way. Basically, just because your forum was hacked and destroyed doesn't necessarily mean that they got in through the forum software.
Title: Re: Why chmod 777 is NOT a security risk
Post by: taha116 on December 30, 2008, 07:43:20 PM
Quote from: Killer Possum on December 30, 2008, 05:31:28 PM
Quote from: taha116 on December 30, 2008, 12:43:48 PM
So its just as easy to hack my 1.1.7 site as it would be to hack this SMF community site? I don't believe that, because if people report getting hacked then why dosent some whacko just hack this too? Their are obviously some differences that you have not considered?

The differences are in the configuration of the server as well. Just because site A gets their forum hacked doesn't mean site B can be hacked in the same way. Basically, just because your forum was hacked and destroyed doesn't necessarily mean that they got in through the forum software.

Ahh so basicly if I were to install SMF 1.1.7 using all recomended settings and nothing else I should be as safe as this site itself?
Title: Re: Why chmod 777 is NOT a security risk
Post by: IchBin™ on December 31, 2008, 12:15:50 AM
No, because each server is configured differently.
Title: Re: Why chmod 777 is NOT a security risk
Post by: Killer Possum on December 31, 2008, 10:14:00 AM
Quote from: taha116 on December 30, 2008, 07:43:20 PM
Ahh so basicly if I were to install SMF 1.1.7 using all recomended settings and nothing else I should be as safe as this site itself?

Like IchBin said, no because each server is configured differently. Not the server settings page in the forum software, but the server itself. And that's left up to your web host to secure, and hopefully you are with a reputable web host for that reason. ;)
Title: Re: Why chmod 777 is NOT a security risk
Post by: taha116 on January 03, 2009, 11:03:22 AM
Quote from: Killer Possum on December 31, 2008, 10:14:00 AM
Quote from: taha116 on December 30, 2008, 07:43:20 PM
Ahh so basicly if I were to install SMF 1.1.7 using all recomended settings and nothing else I should be as safe as this site itself?

Like IchBin said, no because each server is configured differently. Not the server settings page in the forum software, but the server itself. And that's left up to your web host to secure, and hopefully you are with a reputable web host for that reason. ;)

AH, so if i followed the recomended settings from SMF and happened to have a good host that kept my server secure.. i should, in most cases have nothing to worry about.

Just a suggestion as part of this reply its a quick one... joomla has this sort of server check thingy during instilation to see if all recomeded and required features are enabled, maybe SMF should try something like that out...
That would help people know if thy will be able to run SMF properly or not, and also if it would be on a secure server...
Title: Re: Why chmod 777 is NOT a security risk
Post by: Skhilled on January 11, 2009, 03:17:18 AM
Those checks do not necessarily mean that the server is secure. It only checks to see that the software in question will install properly so the software will be more secure...not the server itself.
Title: Re: Why chmod 777 is NOT a security risk
Post by: GravuTrad on February 06, 2009, 01:53:33 PM
for those who understand french and who don't believe that cause thieves exist we have to let our house's door open (without be present)...:

http://www.php-maximus.org/Maximus_CMS_post_t_7357.html
Title: Re: Why chmod 777 is NOT a security risk
Post by: MacGig on February 07, 2009, 07:31:52 AM
I had things set to 777 once and got hacked, the host said that is why. so Im confused.

can someone list what files should be 777, 775, etc? AFTER the install or upgrade?
Title: Re: Why chmod 777 is NOT a security risk
Post by: IchBin™ on February 08, 2009, 12:29:55 AM
Getting hacked isn't caused by 777. Sounds like you're host doesn't know what they're talking about IMO. Getting hacked is usually through bad code that isn't secure, which allows a hacker to exploit the code to do things on the server. Simply having a file set to 777 isn't an exploit. If that was the case, there would be FAR more sites getting hacked out there...
Title: Re: Why chmod 777 is NOT a security risk
Post by: Skhilled on February 08, 2009, 04:24:22 PM
Very true. :)
Title: Re: Using chmod 755 and package manager
Post by: philesq on August 17, 2009, 12:11:09 AM
I would prefer to use 755 which is working, but would like to use package manager.  I could temporarily change the necessary files to 777, use package manager and then change the files back to 755.  Which files what I need to change to 777?
Title: Re: Why chmod 777 is NOT a security risk
Post by: Arantor on August 17, 2009, 07:43:58 AM
philesq: please open a new topic in the support boards.

For reference SMF should be able to set its own permissions if given FTP username/password.
Title: Re: Why chmod 777 is NOT a security risk
Post by: GravuTrad on August 17, 2009, 07:45:31 AM
Quote from: Arantor on August 17, 2009, 07:43:58 AM
For reference SMF should be able to set its own permissions if given FTP username/password.

Not all servers configurations permit this...
Title: Re: Why chmod 777 is NOT a security risk
Post by: Arantor on August 17, 2009, 08:55:43 AM
Quote from: GravuTrad on August 17, 2009, 07:45:31 AM
Not all servers configurations permit this...

True enough - as the support topics testify. However this should be used in the first instance and as ever any problems should get their own support topic.