|
- Readme First! -
Read and follow the rules, otherwise your posts will be closed |
|
|
|
|
|
There are currently, 476 guest(s) and 0 member(s) that are online.
You are Anonymous user. You can register for free by clicking here |
|
|
|
|
|
Bharat replies re:Gallery version 1.3.3 local exploit |
|
 sixonetonoffun writes "Your security questions, answered
Recently there was a post on BugTraq, a well known security mailing list that referred to a security hole in Gallery. You should read the post yourself, but the specific issue that the poster was refers to is the fact that on a shared webserver it's possible for other webserver users (ie, other customers of your ISP) to read and write your data files. In this article, I'm going to discuss in detail the problem, explain why this is not a Gallery specific issue, help you to understand if you're at risk, and outline the steps that you can take to increase your security.
While the bugtraq post is technically correct, it inaccurately portrays Gallery as having a large gaping security hole that we could fix. The truth is that this is not a problem that can be solved by changing code in Gallery. This problem exists with any content management application on a shared webserver with a weak security policy. This includes all the popular content management systems, bloggers, media management tools, database tools, etc. I'm not going to name names, since I don't want to promote the atmosphere of ill-advised finger pointing. However, it's fair to say that if your webserver is managing data for you via a web interface and your ISP hasn't taken specific steps to prevent it, a malicious user can interfere with your data files.
Some might ask, "Wouldn't we have more security if Gallery used a database instead of flat files?" No. Even if you use a database (as many apps do), you must store your database username and password in a configuration file. On servers with poor security models, a malicious user can read that configuration file and then gain access to read and write to your database.
Let me stress again, this is not a problem that can be fixed by changing the Gallery code. This is a problem with the way that ISPs configure their web server. We are well aware of this issue and have done what we can to minimize it. However, the problem lies entirely under the control of the webserver administrator. If you're on a shared server with a poor security model, the only truly secure solution is to not use any tools that manage your data for you. Kiss those community management tools goodbye - they're all vulnerable.
Say you're with an ISP and using a shared webserver. By shared we mean that the server that delivers your web pages is also used by other folks to deliver their web pages. Even if you have your own domain, if you're on an ISP then unless you paid for the dedicated server option you're almost definitely in this situation. You have an account (let's call it "jdoe") and you log in and create files. These files are owned by you, and you can change them so that nobody else can read them. However, the webserver runs as a different user. Just like you have your account, the webserver has its own account (sometimes they use the account "www" or "nobody" for this purpose). So as your ISP may tell you, any HTML pages that you create to publish have to be readable by this user, otherwise the webserver won't be able to read your files and send them to a web browser. Now the problem occurs when you try to store data using the web interface. You're actually asking the webserver to write some files to the filesystem (or save data in the database) on your behalf. So any files that the webserver wants to write must be set so that they are actually writeable by the webserver user. This means that they wind up being owned by the "www" user, not by you the "jdoe" user. You can see where this is leading -- unless your ISP has taken specific steps to block it, anybody who has the ability to install scripts on the web server can run code as the "www" user allowing them to read and write to your sensitive files. Now all of a sudden, your files are vulnerable to attack.
At this point, some folks will ask "won't PHP's safe-mode solve this problem?" Yes, provided your ISP doesn't give malicious users any other way to get at the files (like CGI scripting). Turning on Safe Mode in PHP but allowing CGI access is like triple-locking the front door but leaving the side window open. It creates the illusion of security but is in fact just a hassle for regular users. Sadly, I see many ISPs that go this route, perhaps because it's a very easy security policy to implement.
So I've mentioned poor security model above and given you an example of a weak (but sadly very standard) configuration. There are two ways to thoroughly fix this problem.
Use PHP in CGI mode and use suEXEC. suEXEC is an Apache configuration that allows PHP to run as you (user "jdoe") instead of the webserver (user "www"). This is good because now all of a sudden all your files are owned by you and not a shared user so you can lock them down tight and not worry about security problems.
Use a chroot jail. A chroot jail is a mechanism for compartmentalizing a shared server. Each user gets their own tiny "jail" that has all the amenities that a regular server would have, except that they can't see or touch other users files. This can be tricky to configure correctly, but if done properly can lead to an environment where you not only can't touch another user's files, you can't even tell if they exist or not.
If your ISP uses one of the above models, your data files are suddenly secure (without having to change a line of code in your favorite content management system). If they don't, other users of your server can get at your files and cause all kinds of mischief. If you are unsure whether or not your ISP provides the above functionality to you, you should send them an email and ask them. Send them a pointer to this article and ask them if they can tell you what security model they use. If they use a weak policy, ask them to upgrade their security. If they won't, then consider using a different ISP, consider upgrading to a dedicated server, or be prepared for the possibility that someday somebody may tinker with your files and cause you some pain and suffering.
Full Article"
|
|
Posted on Tuesday, February 11 @ 12:10:01 CET by [RETIRED]chatserv |
|
|
|
|
| |
|
|
| | The comments are owned by the poster. We aren't responsible for their content. |
| | | | |
| No Comments Allowed for Anonymous, please register | | | | |
Bharat replies re:Gallery version 1.3.3 local exploit (Score: 1)
by Zhen-Xjell on Tuesday, February 11 @ 12:29:25 CET
(User Info | Send a Message) http://castlecops.com | Jailing a web site in a chrooted environment is really the way to go in order to protect shared accounts from each other. However as stated setting up a chrooted environment is time consuming and can be tricky because in essence you must re-create the hard drive in a jailed environment.
You have to re-create apache with all the mods, and any other tools like php, perl, etc. And when future upgrades come down the pike, they can't be applied to just the server, but to all the chrooted environments.
So it takes a lot of admin time. Busy work, so to speak.
Optimally the way to go without that annoyance is suexec. If something gets compromised at least it happens as the user. At that point you want to ensure that the user doesn't have access to critical parts of the system. |
| | | | | |
