Gallery 1.3.3

[error]

--=-tiOkxL0KH/8VjLTce2JT
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Vulnerable: gallery version 1.3.3 (other versions not tested)
Url: gallery.sf.net

Local exploit.

Gallery has a security hole where any other user on the same webserver
can create, modify or destroy photos in a given album directory.

Also Gallery requires that you turn off safe mode.

Each gallery setup needs a temp directory and an album directory.

Gallery accesses the album directory in a manner that requires
permissions of 755.

eg:
drwxr-xr-x 5 www wheel 512 Feb 9 16:02 albums

and inside albums:=20
ls -l
total 16
drwxrwxr-x 2 www wheel 3584 Feb 9 16:19 album01
drwxrwxr-x 2 www wheel 5120 Feb 9 16:25 album02
-rw-r--r-- 1 www wheel 65 Feb 9 16:02 albumdb.dat
-rw-r--r-- 1 www wheel 65 Feb 9 16:02 albumdb.dat.bak
-rw-r--r-- 1 www wheel 0 Feb 9 14:05 albumdb.dat.lock
-rw-r--r-- 1 www wheel 11 Feb 9 15:42 serial.dat

As a result anyone who has ever set up a gallery before can just have a
cgi running as user www (or whatever user apache is running as) move
files around.

This can be exploited with everything from SSI, perl to even php.

So on shared hosting gallery is a bad idea.


There is no fix for this as of this time.
This is a product of poor default web application security design.

--=20
error <error@lostinthenoise.net>

--=-tiOkxL0KH/8VjLTce2JT
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+RvLoKvrsP0edi7gRAn8hAKCXO05yIWkW73h/lXElWPYmfWdZLACgwRAC
lJ1JIlMYqEOI9NitvZNJb7M=
=FBH/
-----END PGP SIGNATURE-----

--=-tiOkxL0KH/8VjLTce2JT--

[netsecurity]

I am forwarding this response from the Author of Gallery who posted
the following on his web site at:
http://gallery.menalto.com/modules.p...rder=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@duracompanies.com
-------------------------------------------------------------------------