Ok let me see...
On Mon, 2012-08-06 at 12:49 +0200, Ondřej Surý wrote:
> You forgot to cc cont...@bugs.debian.org
Oops...
> because this is by no means a critical bug.
Well I guess it should be quite obvious that it became one:
Even if you're quote from below (about people should use mod-php5) would
be a good advise, we offer our users the -cgi package AND we tell them
how to configure it.
Now how we told them to do, was kinda flawed, for the reasons I've
already laid out before (the foo.php.jpeg issue, for example)... and
things got worse when the mime-type package dropped the type for php.
As a consequence, no php files were interpreted anymore but (even worse)
just served.
The former is a "breaks unrelated software", the later is a security
issue, as people rely on the php files not being served; which is
arguably bad style and security by obscurity, but nevertheless real
world.
And there's absolutly no reason to take the above (or any other of my
comments) personally or offensive.
The same applies when I (in the past) said that PHP itself has security
issues. This is not meant against you, but I guess it can be easily
shown that we see quite often CVEs... and all I want is to emphasize how
it can be secured as much as possible (therefore also my position
regarding the suhosin discussion).
I like your, Ondřej, and that of the other Debian PHP maintainers
efforts,... but it's unfortunate if such an issue is not considered
critical, just because it's not the usual kind of buffer overrun /
remote code exploit hole.
I think it's clear that a chain thing of bad things happened for this to
occur, including the weird way how Apache handles this.
Nevertheless... :)
> The issue is only in the README file which also clearly states
> (together with hint to use php5-fpm):
>
> In 99% of cases, what you probably want isn't php5-cgi package at
> all, but rather the libapache2-mod-php5 package, which will
> configure itself on installation and Just Work(tm). If, however, you
> have a need to use the CGI version of PHP 5 with Apache HTTP Server,
> the following should help get you going, ***though there are dozens of
> different ways to do this.***
Well I think that hint is at best questionable and in reality likely actually
dangerous.
I know this is also to some extent the position of PHP upstream, but I
guess less because of real technical reasons and more because of that
they want easy out-of-the-box setups.
But it should be quite clear, that mighty systems like PHP must be fully
understood to really maintain them in a secure manner.
The mod-php5 is surely faster than normal CGI, but not much (if at all)
faster than operation with FastCGI.
And from a security (and stability) point of view it's a night mare,
given that it not only runs in the user context of the webserver, but
already really in the webserver (=> stability).
Especially that sites easily host more than one PHP program, which, as a
consequence, all rund as www-data should prevent any careful
administrator from sleeping.
But that's just my 0.02€ on that matter... so back to the actual bug. :)
> If you want to report a bug, you probably should at least check the
> parts your report is about. And no, mod_php is not affected.
As I wrote, I haven't looked that up... and AFAIU mod_php by itself IS
actually affected, as it also needs some handler/action or similar
definition that typically goes by file extension.
It's just Debian's mod_php package that is secure, as it ships an
already (largely) secure .conf snippet.
But, dear Ondřej, a few words on that:
a) You're using <FilesMatch> (in an already quite secure way! :) ) ...
you you really insist on keeping that (more below) please modify it as
follows:
- Add "?:" to the pattern "(p3?|tml)"... i.e. make (?:p3?|tml).
This as now effect on the pattern, it just disables the subpattern
variables (i.e. $1, $2) which we don't use anyway... and makes it
thereby a bit faster.
- as usual, please make files like ".php" (alone) not match,...
typically these are meant as "hidden" files and not as a *.php file.
So I'd suggest to change patterns to e.g. ".+\.phps$"
b) I'd use <Files> though, as it's faster (I guess even though having
more rules) and we don't need the mightiness of PCRE matching.
So we'd get:
<Files ?*.php>
SetHandler application/x-httpd-php
</Files>
<Files ?*.php3>
SetHandler application/x-httpd-php
</Files>
<Files ?*.phtml>
SetHandler application/x-httpd-php
</Files>
<Files ?*.phps>
SetHandler application/x-httpd-php-source
</Files>
c) In any of the two cases, add:
RemoveType php php3 phtml phps
We cannot know, whether the user has made up his own definitions in
e.g. /etc/mime.types or even in Apache itself... and we should do
everything as possible to prevent him from the foo.php.evil.jpeg issue.
The RemoveType is just processed once at server start, so it really
doesn't cost us anything.
> > 1) Add a NEWS item entry, that these mime types were removed
> > from /etc/mime.types and what this could mean.
> > Possibly linking to the above bug.
>
> Release notes addressed from mime-support is fine.
What speaks against adding it too php5-cgi, too? It's just a little
entry and save people possibly from a lot of troubles.
Especially, people are less likely to read all NEWS.Debian entries from
any normal package which is not their core business... but when you have
a site running some PHP program,.... the PHP NEWS.Debian files are
surely something that attract your attention.
If you need help, I can easily write one for you :)
> > RemoveType php
>
> I am not going to add this. If you have a previous mapping somewhere
> else, it's your problem.
Well,... I really don't want to start an argument here with you... but
are there any strong reasons? As said, there is no performance impact
and it should serve as good fallback security.
> > <Files ?*.php>
> > AddType application/x-php php
> > </Files>
> This is a good idea.
Thanks :)
> > ScriptAlias /cgi-bin/php5-cgi /usr/lib/cgi-bin/php5
> > Action application/x-php /cgi-bin/php5-cgi
> > -------------------------------------------------------
> > plus the note, that one SHOULD limit AT LEAST the ScriptAlias and
> > Actionto _only_ such <Directory> blocks, where php files to be
> > interpreted reside.
>
> Again this is just a quick&dirty README and not PHP manual, but I have
> added a reference to CGI Security section in PHP manual.
Thanks :)
Best wishes,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
