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]
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.
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]
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.
How would you say - in brief terms - how a server should be correctly configured?
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?
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
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!!
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?
yes, you can have SMF running properly, but you cant use some features like:
- attachment
- package manager
- Settings.php editor (Forum Preferences and Settings)
kuso~ (>_<#)
I can edit settings without the editor fine, but attachments and package manager I really want to be able to use (-_-;)
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
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
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*
that's precisely the other host we're talking about (~_^)
I need to move something to that other host too ;)
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
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.
If 755 works for you, that is fine. But on some hosts you need 777.
-[Unknown]
More information on the above question:
http://www.simplemachines.org/community/index.php?topic=32991.msg246205#msg246205
-[Unknown]
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.
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...
- 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. :(
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?
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.
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]
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.
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!
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.
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.....
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]
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.
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.
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]
.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...
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.
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]
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.
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]
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.
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]
I've been asked to clarify this again, so let me say the following:
1. Whether you are on a shared server or a dedicated server, on your server there are several directories which must (unavoidably) be 777 - for example, /tmp at the least, and in most situations attachments and possibly other directories. So, we understand that some things must be writable by "nobody" (Apache.)
2. If a file is writable by "nobody" (Apache), or owned by nobody (as attachments will be, since they are created by nobody) they may potentially be written to. This is, again, not avoidable.
3. If your server is compromised, as described above, many of these files may be overwritten, deleted, or otherwise affected negatively by the hacker or script. Again, assuming compromises are unavoidable, this is too - given the above.
So, if we take all of the logical points above, we understand that the server will need to undergo a COMPLETE AUDIT if it is ever hacked. So far, I hope everyone can agree with me, right? If any host believes that you can keep a server running immediately after a script got system or file access, they are not worth paying any money. I hope we can all agree with that statement too, right?
Continuing to assume that file or system access compromises are unavoidable, we know that such access also potentially gives access to delete, modify, or access the entire database. This means that:
- The entire forum could be deleted, which is recoverable if you have backups.
- The list of email addresses, password hashes, and other confidential information could be read, which is not only unavoidable, but also much worse than anything else.
- Forum data could be maliciously modified, in fact things could be done which would be very similar to file modification (for example, someone could replace a board's description with cleverly designed HTML to cover the entire page.)
So, clearly, database access is the worst thing that could happen to you. If a hacker obtains database access they can do practically anything possible by way of file access. I think this has not been sufficiently clear either. While some may disagree with my statement about file access, I hope no one will disagree that the disclosure of personal information to a hacker of malicious intent is hands down worse than the server itself physically exploding.
Obviously, conventional wisdom dictates that files should not be writable by anyone unless necessary. I have never suggested otherwise, and anyone who says I have is miscontruing my meaning. However, my meaning is clear - the "additional" problems possible when files are 777 are minimal at best. They are, as described:
- Files (which are easily obtained from the download page, and never change) may be deleted. Said files should be backed up anyway.
- Files may be maliciously modified. This, as above, is unavoidable (because some directories and files will be 777 nevertheless, like /tmp and attachments) so should always be considered. After being hacked, a server should be wiped and *CLEAN* backups should be restored. No files should ever be trusted, 777 or not.
Additionally, whether 777 or not, files with confidential or important information may be read. This is unavoidable unless Apache does not need to be able to read the files. Again, if a hacker of malicious intent is able to procure confidential information, this is much worse than malicious modification. In some cases, users are not allowed to, or simply do not, have separate passwords between FTP and MySQL. In these (too common, especially in shared hosting) cases, the ship has sunk anyway.
Benefits which come, however, from having files 777:
- Database error reporting works better (it won't send you an error every time it cannot connect, since connection errors usually come in groups.)
- Attachments may be posted, and avatars may be uploaded.
- Templates and themes may be installed and modified from the administrative interface.
- Updates may be installed, clearly increasing security.
- Modifications and packages may be installed, improving general use of the forum.
Of course, many of the above - such as updates - do not require files to be 777 indefinitely. For this reason, the administrative interface includes ways to change the file permissions en mass, to make updates easily installable or to increase (although, as laid out above, by only a very small margin) security. The use of said features is encouraged, but some hosts suggest to their users that files should NEVER be 777, which is what this topic is disagreeing with.
Anyone who says that having files 777 on a shared server is a way to cause or worsen a security problem clearly has no plans to take proper measures to clean up after hacking has occured, and may also think that their system is safe as long as files are not 777. Such blind faith in file permissions is foolish at best. I strongly recommend against paying any money to any such host, unless you wish to promote such bad practices in the industry (and possibly cause your self nasty problems after or during an attack, even with no files 777.)
-[Unknown]
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
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]
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.
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.
"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.
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
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
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.
Did you maybe use hotlink protection in cPanel? It sounds to a similar problem I had in the past with it.
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.
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
CHMOD is not applicable to Windows operating systems. This is a *nix command.
I figured as much was not sure but am I ok with how I have the permissions set?
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.
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.
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 host doesn't allow 777 and all my files are 755
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. ^^
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? ;)
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>
hey wow! Thanks for the gr8 article unknown :)
that was a long thread, and interesting...
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.
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.
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?
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)
try 755 if 777 fail ;)
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.
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 :)
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.
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.
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
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.
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
How do I use chmod? (http://www.simplemachines.org/community/index.php?topic=23690.0)
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
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??
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.
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.
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
yeah, sorry.
found it.
didnt make temp dir in Packages.
tnx. for answer.
666 is ok :)
catalogues 750
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
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.
Is there no way to protect a database completly? Even if it costs some money?
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
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?
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.
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?
No, because each server is configured differently.
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. ;)
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...
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.
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
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?
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...
Very true. :)
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?
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.
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...
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.