Advertisement:

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

Offline permutations

  • Jr. Member
  • **
  • Posts: 320
Re: Why chmod 777 is NOT a security risk
« Reply #20 on: July 24, 2005, 02:05:13 PM »
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.

Offline keepr

  • Newbie
  • *
  • Posts: 4
PLEASE FOLLOW THE ADVICE OF YOUR BRAIN NOT YOUR VENDOR!
« Reply #21 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...
« Last Edit: August 20, 2005, 03:14:06 PM by keepr »

penmin

  • Guest
Re: Why chmod 777 is NOT a security risk
« Reply #22 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. :(

Offline kegobeer

  • SMF Friend
  • SMF Hero
  • *
  • Posts: 3,994
  • Gender: Male
  • I am ninja!
    • The Kazebeer Family Website
Re: Why chmod 777 is NOT a security risk
« Reply #23 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?
"The truth of the matter is that you always know the right thing to do. The hard part is doing it." - Norman Schwarzkopf
Posting and you (Click "WATCH THIS MOVIE")

Offline Thunderace

  • Sr. Member
  • ****
  • Posts: 722
  • Gender: Male
  • I'm still a llama!
    • FWR Media UK
Re: Why chmod 777 is NOT a security risk
« Reply #24 on: August 20, 2005, 05:26:50 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.

Offline [Unknown]

  • SMF Friend
  • SMF Master
  • *
  • Posts: 36,102
  • Gender: Male
Re: PLEASE FOLLOW THE ADVICE OF YOUR BRAIN NOT YOUR VENDOR!
« Reply #25 on: August 20, 2005, 05:28:23 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.

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

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.

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.

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]
« Last Edit: August 20, 2005, 05:30:54 PM by [Unknown] »

Offline keepr

  • Newbie
  • *
  • Posts: 4
Re: Why chmod 777 is NOT a security risk
« Reply #26 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
hxxp:www.governmentsecurity.org/archive/t8454.html [nonactive]

Simple Machine Forum SQL Injection (modify)
hxxp:www.securiteam.com/exploits/5HP0N0KG0O.html [nonactive]

Yabbse 1.5.4 Sql Injection Poc Exploit
hxxp:www.governmentsecurity.org/archive/t6065.html [nonactive]

YaBB/YaBBse Cross Site Scripting Vulnerability
hxxp:seclists.org/lists/bugtraq/2004/Mar/0135.html [nonactive]

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

YabbSE Multiple Vulnerabilities March 2004
hxxp:www.net-security.org/vuln.php?id=3305 [nonactive]

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

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

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.
« Last Edit: August 20, 2005, 09:48:25 PM by keepr »

penmin

  • Guest
Re: Why chmod 777 is NOT a security risk
« Reply #27 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!

Offline tentronik

  • Full Member
  • ***
  • Posts: 499
  • logic is
    • [Roboter]
Re: Why chmod 777 is NOT a security risk
« Reply #28 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
Quote
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

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 over 400k.
or
vBulletin at google over 158k
or
SMF exploit  google 18k

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

« Last Edit: August 20, 2005, 11:27:17 PM by tentronik »

Offline IchBin™

  • SMF Friend
  • SMF Super Hero
  • *
  • Posts: 11,115
  • Gender: Male
  • I don't speak German.
    • IchBin.us
Re: Why chmod 777 is NOT a security risk
« Reply #29 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.....
Brad "IchBin™" Grow        TinyPortal        Themes
Coding Guidelines       

Offline [Unknown]

  • SMF Friend
  • SMF Master
  • *
  • Posts: 36,102
  • Gender: Male
Re: Why chmod 777 is NOT a security risk
« Reply #30 on: August 20, 2005, 11:34:40 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.

Quote
Smf Size Tag Script Injection Vulnerability

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

Quote
Simple Machine Forum SQL Injection (modify)

This provides no access to the server.

Quote
Yabbse 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.

Quote
Yabase 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.

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]

Offline Amacythe

  • SMF Friend
  • SMF Super Hero
  • *
  • Posts: 19,060
  • Gender: Female
Re: Why chmod 777 is NOT a security risk
« Reply #31 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:

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

It really is a shame.  I'd like to hear more about why I shouldn't trust my host to keep my files secure.

Offline Valodim

  • Full Member
  • ***
  • Posts: 417
Re: Why chmod 777 is NOT a security risk
« Reply #32 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.

Offline [Unknown]

  • SMF Friend
  • SMF Master
  • *
  • Posts: 36,102
  • Gender: Male
Re: Why chmod 777 is NOT a security risk
« Reply #33 on: August 20, 2005, 11:50:58 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]

Offline Valodim

  • Full Member
  • ***
  • Posts: 417
Re: Why chmod 777 is NOT a security risk
« Reply #34 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...
« Last Edit: August 20, 2005, 11:59:10 PM by Valodim »

Offline keepr

  • Newbie
  • *
  • Posts: 4
Re: Why chmod 777 is NOT a security risk
« Reply #35 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.

Offline [Unknown]

  • SMF Friend
  • SMF Master
  • *
  • Posts: 36,102
  • Gender: Male
Re: Why chmod 777 is NOT a security risk
« Reply #36 on: August 21, 2005, 12:32:05 AM »
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.

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

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

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.

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

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.

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

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]
« Last Edit: August 21, 2005, 12:33:50 AM by [Unknown] »

Offline Amacythe

  • SMF Friend
  • SMF Super Hero
  • *
  • Posts: 19,060
  • Gender: Female
Re: Why chmod 777 is NOT a security risk
« Reply #37 on: August 21, 2005, 12:38:07 AM »
I'm still trying not to take sides here, but your comment:
Quote
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.
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. 

Offline [Unknown]

  • SMF Friend
  • SMF Master
  • *
  • Posts: 36,102
  • Gender: Male
Re: Why chmod 777 is NOT a security risk
« Reply #38 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]

Offline keepr

  • Newbie
  • *
  • Posts: 4
Re: Why chmod 777 is NOT a security risk
« Reply #39 on: August 21, 2005, 01:28:37 AM »
I'm still trying not to take sides here, but your comment:
Quote
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.
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.
« Last Edit: August 21, 2005, 01:31:24 AM by keepr »