Page 2 of 3

Posted: Tue Feb 14, 2006 10:40 am
by matthijs
wow, i really didn't know all this. I can hardly believe it. If you check out the forums and/or FAQs from many popular scripts, so many times it's advised to just chmod files and /directories to 777 in case of permission problems....

Thanks for the insight. Now I'm going to try and write a script which recursively checks all directories and files on their permission to make sure I haven't left any directories open ..

Posted: Tue Feb 14, 2006 10:44 am
by feyd
yeah, 777 is a bad habit many developers just stick out there as a fix to their, often, poorly coded scripts. You shouldn't have to enable execution ever really.

This feels a lot like the register_globals issues to me.. it's just lazy, bad coding..

Posted: Tue Feb 14, 2006 11:55 am
by neophyte
So if I'm following this thread right, the big threat is 0777 folders on shared hosts because other users on the server can access them readily. But even on a dedicated host you've still got to watch your butt. So to protect yourself:

Put the 0777 directory one level up from the web root.
Deny access to the folder with .htaccess directive
Check to make sure the folder cannot be accessed via anonymous FTP on your server.

Anything else one can do to avoid exploitation?

Posted: Tue Feb 14, 2006 12:17 pm
by Buddha443556
neophyte wrote:Anything else one can do to avoid exploitation?
If you allow web users to upload files to such a folder then give the files random names.

It's still better to avoid the situation altogether if you can.

Posted: Tue Feb 14, 2006 7:37 pm
by seodevhead
If you put the upload folder one level up from the web root... how the heck can you call on the files in this folder from all your webpages? You can't include such a file path in a <a href or <img src tag.

Posted: Tue Feb 14, 2006 7:51 pm
by neophyte
Simple if you're on a shared host with safe_mode off. Assuming I'm on your server as another user, file_get_contents('/absolute/path/to/your/file.php').

Posted: Tue Feb 14, 2006 7:52 pm
by seodevhead
So is it okay to chmod a folder 777? But keep all the files (say all images) inside that folder chmodded to 644 or whatever the default is? I have an image gallery script that is not working at all when I change the upload folder permissions to anything but 777. This image gallery script writes, reads and deletes the images in this uploads folder by it's scripts. Any idea?

Posted: Tue Feb 14, 2006 8:16 pm
by seodevhead
Hey Guys! Check out this article on why he thinks CHMOD 777 is SAFE!!!

http://www.simplemachines.org/community ... pic=2987.0

I am soooo confused and if you guys could read his article and tell me if what he says is true or not... it would be very helpful to me. Does all this chmod 777 stuff really a security risk for guys like me who have a solely dedicated server all to ourselves??? Or is this 777 stuff just a concern for shared hosting guys??? Thanks.

Posted: Tue Feb 14, 2006 8:33 pm
by feyd
He's taking the optimistic approach to it. We're going on the pessimistic side. His post(s) are about a theoretical forum, we're talking about software, any software. Our scope is a little bit larger than his.

Posted: Tue Feb 14, 2006 8:38 pm
by Roja
seodevhead wrote:Hey Guys! Check out this article on why he thinks CHMOD 777 is SAFE!!!

http://www.simplemachines.org/community ... pic=2987.0
The flaw is revealed in his comment two posts down:
The problem is that a lot of servers are not configured properly.
His assumption is "Blame the server configs. With that misconfiguration, there is nothing you can do". Thats not entirely true, and the *reality* is that a lot of servers don't have the secure config that would enable the rest of his comments to be accurate.

Even if they did, even if it was just you, all by yourself, on a dedicated server, if the attacker found *ANY* other way in, its still true that 777 adds risks. Any other scripts, any other exploits, any holes on the server, any password to an admin panel they guess...

The list is long.

Think of it this way.. Do you ask yourself the odds in a parking lot of hundreds of cars, that is well-lit, in a good neighborhood, if your car is likely to be broken into?

NO. You lock your doors, because there is little harm in doing so, and its a smart deterrent.

Same thing here.

Posted: Tue Feb 14, 2006 8:43 pm
by seodevhead
feyd wrote:He's taking the optimistic approach to it. We're going on the pessimistic side. His post(s) are about a theoretical forum, we're talking about software, any software. Our scope is a little bit larger than his.
I am having trouble really grasping the whole concepts being presented here. To make things simple, if I may, let me ask a question about a scenerio that is relevant to me and I would like to seek your professional opinion as to what path I should take as a solution:

I am creating a script that allows users to upload pictures of their cars. These uploaded images are stored in a folder in the filesystem (server). Along with the original uploaded image, the script also creates (using the GD extension) thumbnails for each file and places the thumbs in the same upload folder. This car script does three things. It can view all the car images that were uploaded, it can allow users to upload their car images, and administratively it can delete uploaded car images (if someone was to upload for instance porn).

Now obviously the script needs the upload folder to be readable (so it can call on the images as a URL), and writeable (so it can place/delete the uploads in the directory)... and I'm not sure if it needs execute or not but I guess it does.

This script works perfectly if I chmod the uploads folder 777... but if I change the folder permissions to ANYTHING BUT 777 it does not work at all. If 777 is indeed a security risk, how do I get around this.

The aforementioned option of placing the uploads folder outside the web filesystem won't allow me to call the images as URL's... and I definitely want to call the images by URLs. So it seems this option is out of the cards.

What can I do in this situation? Any help would be extremely appreciated. Thank you for your time and help.

Posted: Tue Feb 14, 2006 8:55 pm
by feyd
have you considered having your script FTP the files? .. You shouldn't need execute, last I checked. Since you've decided you must be able to reference the files directly via url, you need read, yes. Write privledge is only required for PHP. If PHP created the folder, it would own it, which is, overall, the most secure of the permissions (still vulnerable to poor code and config, but taking reasonable precautions is ALWAYS good). If you created the folder via FTP, you may be able to CHOWN the folder to PHP, or just recreate it from PHP.

I would suggest creating a script that performs the image display, as it gives you a bit more dynamic control over how files are viewed and requested. At the same time, placing an .htaccess file in this folder that denies all requests can also help protect it. A word of warning: do not reference the files by name, instead have some way of mapping a hash or id number to a file. However, this breaks away from needing read permission to the world and group on the folder too. ;)

Posted: Tue Feb 14, 2006 8:59 pm
by Roja
seodevhead wrote:Now obviously the script needs the upload folder to be readable (so it can call on the images as a URL), and writeable (so it can place/delete the uploads in the directory)... and I'm not sure if it needs execute or not but I guess it does.
Doesn't need to be executible OR readable, actually. It doesnt even need to be in the webpath. :) Read on..
seodevhead wrote:The aforementioned option of placing the uploads folder outside the web filesystem won't allow me to call the images as URL's... and I definitely want to call the images by URLs. So it seems this option is out of the cards.

What can I do in this situation? Any help would be extremely appreciated. Thank you for your time and help.
Break it down into three tasks, because thats what you have.

You need to be able to receive files from the user - write to a directory.

Now, you *could* get really silly and store them in a database, but thats way over the top security. Just mentioning that that is possible.

Instead, you are more likely to write them to a directory. So, that directory can be outside the webroot, and have 606 permissions. (Read+Write for you and the world). You write the image file to that directory.

Now, your second step is that you would like to be able to create thumbnails of those images. Again, you could go crazy, and process them realtime each page load to avoid writing a file. You could also take the images stored in a db and use gd to process them, also avoiding writing. But we'll ignore those as over the top - just want you to be aware its an option.

So we want to write the thumbnails to that same directory - out of the webroot, 606 permissions.

Finally, you want to *display* those images to the user. You can do this a couple of ways.

The one you probably want is to (after the upload, after the thumbnailing) present the image to the user, from that secured directory. You could do so by importing the images into a gd object, and then dumping it as an image in a specific script, ala http://www.example.com?picture=car.jpg . An example of that is given on the manual page for gd: http://us3.php.net/gd

As I mentioned before, you could also be storing the images in a db, and dumping them to gd, or dumping them direct to the browser.

I *think* you can even dump the image as a binary stream, if you use the right mime type magic, but I've never tried that.

---

The point is, you *can* get around the need to make the same directory readable and writable to the world. There is a tradeoff to do so.

Posted: Tue Feb 14, 2006 9:54 pm
by Benjamin
Correct me if I am wrong but...

The directory itself needs to have execute permissions, otherwise you cannot view it from a browser because it cannot be opened by Apache.

The files in the directory can be chmoded to 0644 without breaking the script. The script will work with a chmod of 766 (for the image directory), but then you won't be able to view the images from a browser. UNLESS you changed the owner of the folder to the owner Apache runs under.

Try adding

Code: Select all

chmod($filename, 0644);
right under the line(s) of code that copy the uploaded image to the image directory.

I think this would solve the problem.

Posted: Wed Feb 15, 2006 2:45 am
by Maugrim_The_Reaper
The linked to articles was pretty funny reading it the first time. 777 permissions are simple lazy programming - I don't mean that in the insulting way, it just a description of a practice that seems extremely popular. I mean if a well known and widely used PHP blog app promotes it (in fact it complains about every permission set EXCEPT 777) then someone somewhere has lost the plot...

Anonymous FTP access should not have access to any directory other than a world writeable "incoming" directory. Otherwise check your host's practices and maybe find a more secure alternative.

Directories do NOT require execute permissions. Read allows access to internal files, or a file listing. Execute permissions allow it to be set as a working directory, i.e. accessed via ssh or other. So 777 is not a good setting for a directory.

Short and easy rule of thumb - Few PHP applications really need a directory with 777 permissions. Not even files need 777 in most cases. If an application states that as a requirement there's a good chance its dead wrong and its encouraging you to practise bad security. Unfortunately its common...