Inspired through the discussion in this, a maybe stupid question.
Most of us have been trained that departing sites or files on Linux-based website hosting using the permission degree of
777 is really a bad factor, and also to give always very little permissions as necessary.
I'm now curious regarding where exactly lies the possibility of exploitation, particularly inside a PHP / Apache context. In the end, a PHP script file could be performed in the outdoors (i.e. via a call towards the web server, and subsequently towards the interpreter) whether or not it's marked as "executable", can't it? And also the same is applicable to files known as with the command-line
php interpreter, right? Where exactly may be the vulnerability with
777? Could it be the truth that other customers on a single machine can access files which are made world writable?
A lot of great solutions, by using imaginable situations, I will need to toss the dice which someone to accept! Thanks everybody for that great input.
Here's one scenario:
- You possess an unguaranteed directory that customers can upload to.
- They upload two files: a spend script, along with a php file which has a
system()get in touch with it towards the spend script.
- they access the php script they simply submitted by going to the url within their browser, leading to the spend script to complete.
If the directory is 777, this means that anybody (such as the user apache, that is what php script will execute as) can execute it! When the execute bit isn't set on that directory and most probably the files within the directory, then step three above would do nothing at all.
edit in the comments: it isn't the PHP file's permissions that matter, it is the
system() call within the PHP file that'll be performed like a a linux systemunix call through the linux user apache (or anything you have apache set to operate as), which is strictly in which the execution bit matters.
It greatly boosts the vulnerability profile of the web site to malicious activity since it is only essential to enter one account.
Anybody that gains use of the body with any login can perform whatever they would like to your website, including altering these to read "This site is actually insecure so please produce your charge card info."
EDIT: (To clarify and address comments)
Many servers have several purpose in existence. They run multiple services. Should you carefully isolate individuals services from one another by setting each a distinctive user and controlling file permissions accordingly, yes, you're still in serious trouble if a person compromises the qualifications to have an account, however the damage they are able to do is restricted to that certain service. If you've just got one generic account and hang the entire file system to 777, one jeopardized account jeopardizes everything around the machine.
In case your server is devoted to simply running Apache/PHP and serves not one other purpose in existence, and there's just one account to which Apache/PHP has been run, getting that certain account jeopardized is just like getting the entire machine jeopardized from the purpose of look at the application (even though you should have system files protected and non-writable through the account accustomed to run PHP... which should still simply be feasible for an admin account/root).
Whether they can write personal files, which is executable, they are able to change it out to something which executes in your machine (executable or script) after which use PHP's spend_professional to operate that executable. If you are set up to not allow spend_professional, they are able to improve your configuration too