[Clipart] fd.o compromised because of our incoming!

[Nathan Eady]

Jon Phillips wrote:

>> clipart.freedesktop.org-access.log:80.99.252.106 - -
>> [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
    necessary.

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
    that way.)

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.