[Clipart] fd.o compromised because of our incoming!
eady at galion.lib.oh.us
Wed Oct 19 14:11:44 PDT 2005
Jon Phillips wrote:
>> clipart.freedesktop.org-access.log:184.108.40.206 - -
>> [17/Oct/2005:15:47:44 -0700] "GET /incoming/winnie_the_pooh.svg.php?x=cd
>> %20/tmp/cvsu;./pwned;id HTTP/1.1" 200 72118 "-" "Mozilla/5.0 (X11; U;
>> FreeBSD i386; en-US; rv:1.7.12) Gecko/20050924 Firefox/1.0.7"
Ugh. I did not realize PHP would be executed from
that directory. I would have thought only directories
that were specifically configured in httpd.conf to have
PHP in them would be treated that way.
>> Looks like a malicious svg/php file. What we feared.
>> Suggestions on how to fix and a fix would be great.
There are several possibilities I can think of here.
1. Do not serve the incoming directory via the web.
It's convenient to be able to wget the incoming
files for doing the release, but it's not
2. Do not accept "other" filetypes, only the ones
on a very short pre-approved list. Off the top
of my head the only ones we really need are .svg
and possibly .zip, but we also could allow .wmf
and .tgz with relative safety, I think. We are
not doing anything useful with any other type
of submission, anyway.
3. Always append an extension (that will cause Apache
not to treat them as executable) to every accepted
file when placing it in the incoming directory.
4. Configure Apache so that executables or scripts
or PHP or whatnot are not run from the incoming
directory, or the clipart directory, or other
such places where they do not belong. Frankly
I cannot think of any very good reason to allow
anything other than static content outside of the
cgi-bin directory. (Yeah, we currently have PHP
content outside of cgi-bin, notably in the document
root, but there's no good reason it *needs* to be
Actually, I think I'd be in favor of doing all four of
these things, and anything else we can think of to lock
down what the web server will automatically do without
approval from someone with an ssh account.
More information about the clipart