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

[Nicu Buculei]

Nathan Eady wrote:
> 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.

PHP can be installed as CGI or as an Apache module, the prefered method 
is the second one.
Keep in ming that PHP scripts does not work in the same way as Perl 
scripts, they are embedded in the HTML pages and are interpreted at 
dysplay time, so it make sense to have them on the entire website, not 
only in a single directory.

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

This mean we will lose the ability to list the latest uploads and review 
them from a convenient interface (web) before a release. This is not good.

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

Agreed.

I do not understand one thing: for files wich are not SVG, usually a RDF 
file with metadata is created, but for this file we don't have a 
winnie_the_pooh.[svg.]rdf.
I guess the uploader was tricked by the .svg.php extension, but then it 
should have put the metadata *inside* the file.
this make me think we have a bug in the upload script

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

this is coupled with 2., if someone submited a SVG file, it must have 
the .svg extension

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

As I said before, I don't think this is doable, but we definitely can 
limit what external programs can be run form a PHP script (with the 
"system()" command):
http://ro2.php.net/manual/en/function.system.php
http://ro2.php.net/manual/en/features.safe-mode.php#ini.safe-mode-exec-dir

-- 
nicu