SMF 2.1.3 has been released! Take it for a spin! Read more.
Started by [Unknown], November 20, 2003, 03:41:19 AM
Quote from: keepr on August 21, 2005, 01:28:37 AMActually the hosting company I was referring to is Interland.
Quotethat files with a permission setting of 777 can be deleted by any user / application.
Quote from: tentronik on August 23, 2005, 12:54:23 AMBut 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.
QuoteAnd isnt 755 a diffrent?
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
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?
QuoteIf I got this far, I could have EASILY gotten the password from the user. I can bruteforce the password if not.
Quote from: carlatf on December 27, 2005, 10:18:31 AMHi 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 vardrwxr-xr-x 12 root root 4.0K Oct 7 08:40 wwwdrwxr-x--x 8 root root 4.0K Oct 18 19:33 usersdrwxrwxr-x 3 apache root 4.0K Aug 21 00:09 BLABLAdrwxrwxr-x 7 apache BLABLA 4.0K Dec 4 00:00 MYDOMAIN.com.ardrwxrwxr-x 17 apache BLABLA 4.0K Dec 6 02:35 public_htmldrwxrwxrwx 8 apache BLABLA 4.0K Nov 27 07:24 forosdrwxrwxrwx 2 apache BLABLA 4.0K Dec 27 00:22 attachmentsBefore 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: David on November 20, 2003, 03:48:49 AMThe 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.
QuoteFirst 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 whohas write privileges on the server).Many exploits are published on various hacker sites and appear on the bugTraq mailinglist at least a few times per year.Secondly, you can use suExec even when you are using PHP as an Apache module. suExec isnot 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 byCGI scripts. If so, this thought is wrong. (If you are not indicating this, accept myapologies). If you install suExec as part of httpd (which is almost always how it isinstalled), 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 asuser "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 goto a web site and cause the web server to do "bad" things to the file system as can anyuser who can write to the specific directory or file, why does it matter what usernameis being used?Look at it this way: "UserA" has write privileges to the /images directory. We suExec ascript to write files to the /images directory as UserA.UserB writes a mailicious script that suExec's to be UserA and deletes the contents ofthe /images directory. How is this more secure than UserA having an /images directoryowned 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 ANYTHINGthat is owned by UserA! If the /images directory were owned by "nobody" and everythingelse was owned by UserA, the potential damage would haved stopped at the /imagesdirectory.My point is that neither one is really "secure," but suExec is not better than givingwrite premissions to a non-privileged account. As a matter of fact, in certaininstances, it can be much worse.As a matter of fact, suExec'ing the script as a real user then gives me the ability touse my malicious script to overwrite ANYTHING that is owned by that user (usually theuser'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 aspermissions are specifically granted by a sys admin. This does mean that certainfiles or folders are succeptible to abuse, but it also means that the sys admin has tobe 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 nottruly understand what the implications of their decision could be. I know that you arefairly knowledgeable dealing with scripts, etc., so you may be the exception to thisrule.I also would never profess to know as much as I would like to know about security. I'mtrying to learn every chance I get by asking as many questions as I can.