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

[Nathan Eady]

Nicu Buculei wrote:

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

They work pretty much exactly the same way.  They are written,
mixed together with HTML as desired, into the files on the
filesystem and interpreted at *request* time (not display time;
Javascript is interpreted at display time).  In principle, this
is exactly the same as cgi.  (PHP reduces the amount of process
forking going on, because it embeds the interpreter in the
web server as a module (in much the same way as mod_perl) but
the way that the scripting code and HTML are intermixed in
the file (e.g., whether the HTML is embedded in strings or
the script in processing directives) is neither here nor there,
frequent zealous advocacy to the contrary notwithstanding.)

> so it make sense to have them on the entire website, not
> only in a single directory.

>From a security perspective, this does not make so much sense.

Fundamentally, security best practice is to disallow by default
and allow only as needed.  Active code should not be executed
by an internet service in response to a request from the
network unless that particular active code has been specifically
approved to be executed, either in the service's configuration
or at the filesystem level (with an execute permission);
ideally both should be required.  This same rule would apply
to a mail service, a domain resolution service, or any other
kind of service.

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

They would still be accessible to things running on the site, so that we
could build an interface for reviewing them, a la what we had envisioned
doing with the DMS.

This is not the first problem, nor the second nor the third, that we
have had at least partly as a result of serving out the incoming
directory via the web.  It's the most serious, but the other problems
may actually be harder to solve in other ways.

> 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

Could be.  I don't have the ability to look right now.
(Hopefully soon.  Newegg has shipped my components...)
One of my first thoughts here is wondering if I was too
general when I added in support for gzipped .svg files,
with extensions like .svg.gz and .svgz, which don't end
in .svg directly.  But I'll have to look at the code to
really know.

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

It should have, if it were recognised as .svg by the
automatic filetype detection.  So yeah, there probably
is a bug of some kind.  But I think fixing the bug in
question is not the only action we should take.