[NBLUG/talk] Fwd: Re: Gallery 1.3.3

Mark Street jet at sonic.net
Fri Jun 20 19:50:04 PDT 2003


And this is in response to the post by error regarding the security problems 
with gallery. ; )  The truth, the whole truth, so help me God.  I save my old 
Bugtraq posts.....  This discussion might help Augie with his decision.

----------  Forwarded Message  ----------

Subject: Re: Gallery 1.3.3
Date: Tuesday 11 February 2003 06:52
From: netsecurity <netsecurity at duracompanies.com>
To: bugtraq at securityfocus.com

I am forwarding this response from the Author of Gallery who posted
the following on his web site at:
http://gallery.menalto.com/modules.php?op=modload&name=News&file=article&sid=
67&mode=thread&order=1&thold=0

:::Begin Forwarded Message:::

Recently there was a post on BugTraq, that referred to a security hole
in Gallery (http://online.securityfocus.com/archive/1/311161.  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.

        1. 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.

        2. 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.

:::End Forwarded Message:::

      (C)opyright Dura Builders, Inc. ~ 2002 ~ Indianapolis, IN,
                            All Rights Reserved
-------------------------------------------------------------------------
The  information  contained  in   this  e-mail   message is confidential,
intended   only  for the  use of  the  individual or  entity named above.
If  the  reader  of this e-mail is  not  the  intended recipient,  or the
employee or  agent  responsible to  deliver it to the intended recipient,
you are hereby  notified  that any  review,  dissemination,  distribution
or copying  of  this  communication  is strictly prohibited.  If you have
received  this e-mail  in error,    contact netsecurity at duracompanies.com
-------------------------------------------------------------------------

-------------------------------------------------------

-- 
Mark Street, D.C.
Red Hat Certified Engineer
Cert# 807302251406074
--
Key fingerprint = 3949 39E4 6317 7C3C 023E  2B1F 6FB3 06E7 D109 56C0
GPG key http://www.streetchiro.com/pubkey.asc




More information about the talk mailing list