[Clipart] fd.o compromised because of our incoming!
nicu at apsro.com
Thu Oct 20 00:04:38 PDT 2005
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
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.
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
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
More information about the clipart