Debian Bug report logs - #674089
mime-support: removed application/x-httpd-* can lead to immense security problems

Package: php5; Maintainer for php5 is (unknown);

Reported by: Christoph Anton Mitterer <calestyo@scientia.net>

Date: Wed, 23 May 2012 01:03:02 UTC

Severity: critical

Tags: security, upstream

Done: Charles Plessy <plessy@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox

Report forwarded to debian-bugs-dist@lists.debian.org, team@security.debian.org, secure-testing-team@lists.alioth.debian.org, Brian White <bcwhite@pobox.com>:
Bug#674089; Package mime-support. (Wed, 23 May 2012 01:03:04 GMT) (full text, mbox, link).

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
New Bug report received and forwarded. Copy sent to team@security.debian.org, secure-testing-team@lists.alioth.debian.org, Brian White <bcwhite@pobox.com>. (Wed, 23 May 2012 01:03:04 GMT) (full text, mbox, link).

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

Package: mime-support
Version: 3.52-1
Severity: critical
Tags: security
Justification: breaks unrelated software


Hi.

In 3.52-1 you removed application/x-httpd-* to close #589384.

This happened without any notice to the NEWS files and I really
wonder whether any though has been spent on which tremendous
security effects this can have.

Given that most people (reasonably) rely on /etc/mime.types
to determine the MIME type for files e.g. with Apache removal
of the above means e.g. that php scripts are no longer determined
as such, but now diretcly shown as text files.

With all secruity effects you can think of and all you even can't
think of.
And of course it breaks countless of working installations
using e.g. php.


a) If you make such a tremendous change you have to announce it
in the release file.


b) Removing the type is definitly the wrong decision.
Apache provides many means to change the handlers and if all that
shouldn't work (which I doubt) on can simply disable the use of
/etc/mime.types.
It's not the business of mime.type to please any specifc user,...
like it seems to me with the aforementioned bug.
Nor should it be mime.type's business to please any software if that
was borken (but as said, apache is not).



Obviously application/x-* are not official flags, but if that was
the reason we'd have to remove much more than just the php ones.



Cheers,
Chris.


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.17-heisenberg (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

mime-support depends on no packages.

Versions of packages mime-support recommends:
ii  file  5.11-1

mime-support suggests no packages.

-- no debconf information

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#674089; Package mime-support. (Thu, 31 May 2012 11:09:03 GMT) (full text, mbox, link).

Acknowledgement sent to Brian White <bcwhite@pobox.com>:
Extra info received and forwarded to list. (Thu, 31 May 2012 11:09:07 GMT) (full text, mbox, link).

Message #10 received at 674089@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

>
> In 3.52-1 you removed application/x-httpd-* to close #589384.
>

I have no preference to it being present or not.  It was marked as "release
critical" by the Apache/PHP folks.  Decide among yourselves what is correct
and I'll make it that way.

-- Brian


>
> This happened without any notice to the NEWS files and I really
> wonder whether any though has been spent on which tremendous
> security effects this can have.
>
> Given that most people (reasonably) rely on /etc/mime.types
> to determine the MIME type for files e.g. with Apache removal
> of the above means e.g. that php scripts are no longer determined
> as such, but now diretcly shown as text files.
>
> With all secruity effects you can think of and all you even can't
> think of.
> And of course it breaks countless of working installations
> using e.g. php.
>
>
> a) If you make such a tremendous change you have to announce it
> in the release file.
>
>
> b) Removing the type is definitly the wrong decision.
> Apache provides many means to change the handlers and if all that
> shouldn't work (which I doubt) on can simply disable the use of
> /etc/mime.types.
> It's not the business of mime.type to please any specifc user,...
> like it seems to me with the aforementioned bug.
> Nor should it be mime.type's business to please any software if that
> was borken (but as said, apache is not).
>
>
>
> Obviously application/x-* are not official flags, but if that was
> the reason we'd have to remove much more than just the php ones.
>
>
>
> Cheers,
> Chris.
>
>
> -- System Information:
> Debian Release: wheezy/sid
>  APT prefers unstable
>  APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.2.17-heisenberg (SMP w/2 CPU cores; PREEMPT)
> Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> mime-support depends on no packages.
>
> Versions of packages mime-support recommends:
> ii  file  5.11-1
>
> mime-support suggests no packages.
>
> -- no debconf information
>
>

[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Brian White <bcwhite@pobox.com>:
Bug#674089; Package mime-support. (Thu, 31 May 2012 16:36:03 GMT) (full text, mbox, link).

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Brian White <bcwhite@pobox.com>. (Thu, 31 May 2012 16:36:03 GMT) (full text, mbox, link).

Message #15 received at 674089@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

So from my side I'd say the following:

1) IF a change like this happens,.. it definitely must go to the NEWS
file, as - in the case of Apache HTTPD Server - it can even have
security relevant outcomes.
So Brian, as long as this change stays, could you please add such
information?

2) I Agree with Thijs (IIRC it was him) comment, that there are security
implications in apache, i.e. that the mime.types file _alone_ would also
have files like foo.php.jpeg marked as application/x-httpd-php and
therefore possibly interpreted as PHP code (which is well known, but
stupid and dangerous anyway.
But that's easy to solve, see below.

3) Given that mime.types may be used by many programs, which may want to
know about PHP files as well... it's a bad idea to fix Apache HTTPD's
stupidity (well at least "difficult" extension handling) by removing
types from mime.types.

I therefore propose the following changes, which should be also ok for
the apache folks:

a) Add these type definitions back to mime.types

b) in the mime.conf of Apache, add:
----------------
#Note: The following is a security measure to remove any possible mappings that would also apply on “middle extensions” (for example “test.php.png”).
RemoveType php
<Files ?*.php>
AddType application/x-httpd-php php
</Files>
----------------
Motivation:
- AddHandler php5-cgi .php alone makes that any file that has the "php" extension at any
place, e.g. also example.php.jpeg being interpreted by php, which can lead to the usual
security attacks.
Putting that in a <Files ?*.php> block, prevents this and only files ending in ".php"
(which excludes the file ".php" itself) will be interpreted.

- The "RemoveType php" removes any previous possible mappings that may also affect the
"middle extensions".
The current /etc/mime.types file in Debian does not longer set a MIME type for PHP so
with that one it's not a problem,... but IMHO that should return to mime.types as it's
not the business of that file to secure the strange extensions handling from apache.

c) instead or in addition to (b)
Disable the "TypesConfig /etc/mime.types" per default in the apache config shipped with Debian.
Given how Apache works with that it can be dangerous and perhaps it would be better if admins have to manualla enable it.

Apache folks,... what do you think?

Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Brian White <bcwhite@pobox.com>:
Bug#674089; Package mime-support. (Thu, 31 May 2012 17:24:04 GMT) (full text, mbox, link).

Acknowledgement sent to Raphael Geissert <geissert@debian.org>:
Extra info received and forwarded to list. Copy sent to Brian White <bcwhite@pobox.com>. (Thu, 31 May 2012 17:24:04 GMT) (full text, mbox, link).

Message #20 received at 674089@bugs.debian.org (full text, mbox, reply):

On Thursday 31 May 2012 11:33:19 Christoph Anton Mitterer wrote:
> I therefore propose the following changes, which should be also ok for
> the apache folks:
> 
> a) Add these type definitions back to mime.types

No, they don't even describe .php files correctly. There should really be no 
application/x-httpd-* entry in mime.types.

Perhaps .php and others should be added back as text/x-php and a NEWS entry 
added.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net

Information forwarded to debian-bugs-dist@lists.debian.org, Brian White <bcwhite@pobox.com>:
Bug#674089; Package mime-support. (Thu, 31 May 2012 23:57:06 GMT) (full text, mbox, link).

Message #25 received at 674089@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Thu, 2012-05-31 at 12:21 -0500, Raphael Geissert wrote:
> No, they don't even describe .php files correctly. There should really be no 
> application/x-httpd-* entry in mime.types.
Why not? application is the designated type family for scripts.

> Perhaps .php and others should be added back as text/x-php and a NEWS entry 
> added.

Well surely not text/ ... IETF itself deprecated the use of e.g.
text/ecmascript and friends..

But I agree that /x-php would be better than /x-httpd-php.

Nevertheless... isn't the later now some kind of conventional
pseudo-standard?

Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Brian White <bcwhite@pobox.com>:
Bug#674089; Package mime-support. (Fri, 01 Jun 2012 14:21:04 GMT) (full text, mbox, link).

Acknowledgement sent to Stefan Fritsch <sf@debian.org>:
Extra info received and forwarded to list. Copy sent to Brian White <bcwhite@pobox.com>. (Fri, 01 Jun 2012 14:21:06 GMT) (full text, mbox, link).

Message #30 received at 674089@bugs.debian.org (full text, mbox, reply):

On Thursday 31 May 2012, Christoph Anton Mitterer wrote:
> So from my side I'd say the following:
> 
> 1) IF a change like this happens,.. it definitely must go to the
> NEWS file, as - in the case of Apache HTTPD Server - it can even
> have security relevant outcomes.
> So Brian, as long as this change stays, could you please add such
> information?

Documenting this in a prominent place is a good idea. I would vote for 
the release notes plus either apache2 or mod_php NEWS file. It seems 
exessive to have it in the mime-support NEWS file since it is just 
noise to all non-apache2 users.

> 
> 2) I Agree with Thijs (IIRC it was him) comment, that there are
> security implications in apache, i.e. that the mime.types file
> _alone_ would also have files like foo.php.jpeg marked as
> application/x-httpd-php and therefore possibly interpreted as PHP
> code (which is well known, but stupid and dangerous anyway.
> But that's easy to solve, see below.
> 
> 3) Given that mime.types may be used by many programs, which may
> want to know about PHP files as well... it's a bad idea to fix
> Apache HTTPD's stupidity (well at least "difficult" extension
> handling) by removing types from mime.types.

The x-httpd- types are really historic ballast from the time there was 
no separate way to configure the handler (Apache 1.3.x or even 1.2.x). 
Because of their special properties, they are called magic MIME types 
in apache httpd. Therefore I think they should be considered an 
internal (and deprecated) implementation detail of apache httpd and 
should not be used as real MIME types anywhere else.

As #589384 explained, declaring them globally is bad for security. And 
it would be really strange to set these magic types globally just to 
remove them with "RemoveType php" again in the default apache2 
configuration.

But adding a different type for .php to /etc/mime.types is fine with 
me. There is some discussion at http://cweiske.de/tagebuch/php-
mimetype.htm which type may be best. Both text/x-php and 
application/x-php seem ok to me.

Cheers,
Stefan

Information forwarded to debian-bugs-dist@lists.debian.org, Brian White <bcwhite@pobox.com>:
Bug#674089; Package mime-support. (Fri, 01 Jun 2012 15:24:02 GMT) (full text, mbox, link).

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Brian White <bcwhite@pobox.com>. (Fri, 01 Jun 2012 15:24:03 GMT) (full text, mbox, link).

Message #35 received at 674089@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Fri, 2012-06-01 at 16:16 +0200, Stefan Fritsch wrote:
> I would vote for 
> the release notes plus
Release notes is a good idea, Stefan, Brian... can anyone of you take
care of this or should I (but I'm on vacation starting next Tue, so that
would take some time).

>  either apache2 or mod_php NEWS file. It seems 
> exessive to have it in the mime-support NEWS file since it is just 
> noise to all non-apache2 users.
I'm not sure whether I can agree...
At least mod_php is not enough,... people seem to always forget that
it's totally ok (and IMHO from a security point of view even much
better) to run PHP as CGI.

Neither am I sure, whether Apache is enough, there may be other
webservers in Debian that could use mime.types (though I haven't checked
this).

In principle, as mime-types is the canonical location of the change, the
safest place to put it, would be there.


> see below.
Stefan, you haven't commented on this...
I've already opened #674205, where I ask the php people to include what
I'd consider the "safest/best" way to handle PHP mime-type in Apache.

IF mime.types will really ship no further definitions for PHP  AND  if
that change is accordingly documented in release-notes/NEWS file(s) than
I think there should be no definitions for PHP in Apache's default
configs at all.


> The x-httpd- types are really historic ballast from the time there was 
> no separate way to configure the handler (Apache 1.3.x or even 1.2.x). 
> Because of their special properties, they are called magic MIME types 
> in apache httpd. Therefore I think they should be considered an 
> internal (and deprecated) implementation detail of apache httpd and 
> should not be used as real MIME types anywhere else.
If we see it from that point, and given that the types are */httpd-*
then I'm in principle ok with your interpretation and dropping it from
mime.types.
But we should perhaps check (how?) whether any other packages have
started to use that mime type (things like nautilus/file/etc.)


> As #589384 explained, declaring them globally is bad for security. And 
> it would be really strange to set these magic types globally just to 
> remove them with "RemoveType php" again in the default apache2 
> configuration.
Agreed upon. I've added this just a s safety measure to remove any
definitions for .php that are potentially already in place and are prone
to the "foo.php.jpeg" problem.


> But adding a different type for .php to /etc/mime.types is fine with 
> me. There is some discussion at http://cweiske.de/tagebuch/php-
> mimetype.htm which type may be best. Both text/x-php and 
> application/x-php seem ok to me.
As outlined before, I wouldn't use text/ anymore... and further... I'd
strongly recommend against any type that is not and */x-* type...
(unless there was an official delegation).

OTOH,... there's no need to discuss such a type now, right? As soon as
someone needs it, he will step up.


Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Brian White <bcwhite@pobox.com>:
Bug#674089; Package mime-support. (Fri, 01 Jun 2012 15:39:05 GMT) (full text, mbox, link).

Acknowledgement sent to Arno TÃ¶ll <arno@debian.org>:
Extra info received and forwarded to list. Copy sent to Brian White <bcwhite@pobox.com>. (Fri, 01 Jun 2012 15:39:05 GMT) (full text, mbox, link).

Message #40 received at 674089@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On 01.06.2012 17:21, Christoph Anton Mitterer wrote:
> Neither am I sure, whether Apache is enough, there may be other
> webservers in Debian that could use mime.types (though I haven't checked
> this).

Lighttpd - at very least - uses /etc/mime.types as well.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Brian White <bcwhite@pobox.com>:
Bug#674089; Package mime-support. (Sat, 02 Jun 2012 14:51:03 GMT) (full text, mbox, link).

Acknowledgement sent to Stefan Fritsch <sf@debian.org>:
Extra info received and forwarded to list. Copy sent to Brian White <bcwhite@pobox.com>. (Sat, 02 Jun 2012 14:51:04 GMT) (full text, mbox, link).

Message #45 received at 674089@bugs.debian.org (full text, mbox, reply):

On Friday 01 June 2012, Christoph Anton Mitterer wrote:
> Release notes is a good idea, Stefan, Brian... can anyone of you
> take care of this or should I (but I'm on vacation starting next
> Tue, so that would take some time).

There is still plenty of time. If you get to it first please cc: 
debian-apache@lists.debian.org so that we may comment on the wording.

> >  either apache2 or mod_php NEWS file. It seems
> > 
> > exessive to have it in the mime-support NEWS file since it is
> > just noise to all non-apache2 users.
> 
> I'm not sure whether I can agree...
> At least mod_php is not enough,... people seem to always forget
> that it's totally ok (and IMHO from a security point of view even
> much better) to run PHP as CGI.

OK, make that mod_php and php-cgi. AFAICS the type is not relevant for 
FCGI.

> 
> Neither am I sure, whether Apache is enough, there may be other
> webservers in Debian that could use mime.types (though I haven't
> checked this).

I haven't found any hint that that type is relevant for either 
lighttpd or nginx. And the change has been quite some time ago and 
nobody has complained so far.

> > see below.
> 
> Stefan, you haven't commented on this...
> I've already opened #674205, where I ask the php people to include
> what I'd consider the "safest/best" way to handle PHP mime-type in
> Apache.

Except for the "RemoveType php" your suggestion is not very different 
from what is in mod_php's config already. And I disagree about mime-
type versus handler: This is exactly what handlers are for. The fact 
that mime-types also work is only for backward compatibility.

> IF mime.types will really ship no further definitions for PHP  AND 
> if that change is accordingly documented in release-notes/NEWS
> file(s) than I think there should be no definitions for PHP in
> Apache's default configs at all.

Hu? Apache's default config has only minimal php relevant elements 
(SSLOptions +StdEnvVars, DirectoryIndex index.php). But mod_php should 
certainly include everything in it config that is necessary to make it 
work.

> But we should perhaps check (how?) whether any other packages have
> started to use that mime type (things like nautilus/file/etc.)

I can see no reason that other apps may handle it specially and none 
has complained so far.

Cheers,
Stefan

Information forwarded to debian-bugs-dist@lists.debian.org, Mime-Support Maintainers <mime-support@plessy.org>:
Bug#674089; Package mime-support. (Wed, 01 Aug 2012 00:06:03 GMT) (full text, mbox, link).

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Mime-Support Maintainers <mime-support@plessy.org>. (Wed, 01 Aug 2012 00:06:03 GMT) (full text, mbox, link).

Message #50 received at 674089@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hey folks.


How are things going with this issue?


I guess what I propose here
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674089#35) is the
best/safest way to go:

1) something in the release notes
2) the NEWS files of at least
  mime-types, apache, php5-common (mod_php is not enough)
  likely also lighthttpd... maybe even more (nautilus? everything using
mime-types?)
3) don't then add any "default" PHP type/handler definitions in the
apache config... remove any existing ones.

Optionally:
4) Add back a php mime type to mime-types.
As outline above... I strongly suggest:
application/x-php
for this:
Neither text/*... nor */php.


The root of this bug is obviously a) apache's strang handling of
mime-types and handlers and b) lack of clear _and_ safe rules provided
by php upstream/deb-package for the end user, on how to enable php.


5) As noted before, I've opened #674205,... where I suggest the IMHO,
safest way to get PHP enabled in Apache (there for CGI)...

We should lobby the PHP Debian maintainers to add to what I propose
there... and also add according documentation for non-CGI php, mainly
this:
#Note: The following is a security measure to remove any possible
mappings that would also apply on “middle extensions” (for example
“test.php.png”).
RemoveType php
<Files ?*.php>
        AddType application/x-httpd-php php
</Files>

wihtout the ScriptAlias and Action.


See that bug which explains the motivation behind the Remove Type and the Files section


Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Marked as found in versions mime-support/3.48-1. Request was from Charles Plessy <plessy@debian.org> to control@bugs.debian.org. (Sat, 04 Aug 2012 03:45:06 GMT) (full text, mbox, link).

Added tag(s) upstream. Request was from Charles Plessy <plessy@debian.org> to control@bugs.debian.org. (Sat, 04 Aug 2012 03:45:07 GMT) (full text, mbox, link).

Merged 664691 674089 Request was from Charles Plessy <plessy@debian.org> to control@bugs.debian.org. (Sat, 04 Aug 2012 03:45:07 GMT) (full text, mbox, link).

Information forwarded to debian-bugs-dist@lists.debian.org, Mime-Support Maintainers <mime-support@plessy.org>:
Bug#674089; Package mime-support. (Sat, 04 Aug 2012 03:48:03 GMT) (full text, mbox, link).

Acknowledgement sent to Charles Plessy <plessy@debian.org>:
Extra info received and forwarded to list. Copy sent to Mime-Support Maintainers <mime-support@plessy.org>. (Sat, 04 Aug 2012 03:48:03 GMT) (full text, mbox, link).

Message #61 received at 674089@bugs.debian.org (full text, mbox, reply):

Le Wed, Aug 01, 2012 at 01:54:30AM +0200, Christoph Anton Mitterer a écrit :
> 
> I guess what I propose here
> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674089#35) is the
> best/safest way to go:
> 
> 1) something in the release notes
> 2) the NEWS files of at least
>   mime-types, apache, php5-common (mod_php is not enough)
>   likely also lighthttpd... maybe even more (nautilus? everything using
> mime-types?)
> 3) don't then add any "default" PHP type/handler definitions in the
> apache config... remove any existing ones.

Dear all,

do I understand correctly that the problem would be solved by documenting the
change in the release notes ?

If yes, can somebody write a draft and reassign this bug to the release-notes
packages ?

Have a nice day,

-- 
Charles Plessy
Co-maintainer of the mime-support package
Tsurumi, Kanagawa, Japan

Information forwarded to debian-bugs-dist@lists.debian.org, Mime-Support Maintainers <mime-support@plessy.org>:
Bug#674089; Package mime-support. (Sun, 12 Aug 2012 23:48:03 GMT) (full text, mbox, link).

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Mime-Support Maintainers <mime-support@plessy.org>. (Sun, 12 Aug 2012 23:48:03 GMT) (full text, mbox, link).

Message #66 received at 674089@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Sat, 2012-08-04 at 12:44 +0900, Charles Plessy wrote:
> do I understand correctly that the problem would be solved by documenting the
> change in the release notes ?
Well as said, I do _NOT_ consider this to be enough (see my previous
mail for my proposed steps).

> If yes, can somebody write a draft and reassign this bug to the release-notes
> packages ?

What about:
-------------------------------------------------------
mime-types package dropped non-standard definitions for PHP that might
affect any systems using PHP
---
The package mime-types has dropped the following non-standard
definitions:
application/x-httpd-php                        phtml pht php
application/x-httpd-php-source                 phps
application/x-httpd-php3                       php3
application/x-httpd-php3-preprocessed          php3p
application/x-httpd-php4                       php4
application/x-httpd-php5                       php5

Systems, especially webservers (including but possibly not limited to
the Apache HTTPD Server) may have used this to mark files as having the
a PHP Internet Media Type (commonly known as MIME type).
They may have used it further, to determine that such files are to be
interpreted by PHP rather than served as normal files.

If a webserver would not consider these files to be interpreted anymore
this would have at least the following effects:
- PHP web programs/sites no longer work
- PHP files are directly exposed, which may be a security problem

In order to avoid any problems, read the README.Debian from the
php5-common package on how to correctly configure PHP (examples are
provided for the Apache HTTPD Server) and take care, that and PHP files
intended to be interpreted are recognised as such (typically by adding
MIME-Type or handler definitions in the webserver configuration).

More information can be found in bug #674089 and partially in #674205.
-------------------------------------------------------

As you can see, I personally would put the burden of explaining how to
(securely) configure PHP to the PHP packages...
I have some discussions about that with Ondřej in #674205 ... I'm not
yet fully happy with it (see there)... and although he closed the bug
and said he'd have applied some of my proposals, I could not yet find
these changes there.

I haven't yet reassigned the bug, as I think my other steps of what I
think should be done will get finally lost then.

Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Mime-Support Maintainers <mime-support@plessy.org>:
Bug#674089; Package mime-support. (Mon, 13 Aug 2012 23:09:04 GMT) (full text, mbox, link).

Acknowledgement sent to Charles Plessy <plessy@debian.org>:
Extra info received and forwarded to list. Copy sent to Mime-Support Maintainers <mime-support@plessy.org>. (Mon, 13 Aug 2012 23:09:04 GMT) (full text, mbox, link).

Message #71 received at 674089@bugs.debian.org (full text, mbox, reply):

Hi Christoph and PHP maintainers,

my answers follow this long quote about a possible release note.

For those in CC, please tell if you do not want to get copies anymore.

Le Mon, Aug 13, 2012 at 01:44:23AM +0200, Christoph Anton Mitterer a écrit :
> 
> What about:
> -------------------------------------------------------
> mime-types package dropped non-standard definitions for PHP that might
> affect any systems using PHP
> ---
> The package mime-types has dropped the following non-standard
> definitions:
> application/x-httpd-php                        phtml pht php
> application/x-httpd-php-source                 phps
> application/x-httpd-php3                       php3
> application/x-httpd-php3-preprocessed          php3p
> application/x-httpd-php4                       php4
> application/x-httpd-php5                       php5
> 
> Systems, especially webservers (including but possibly not limited to
> the Apache HTTPD Server) may have used this to mark files as having the
> a PHP Internet Media Type (commonly known as MIME type).
> They may have used it further, to determine that such files are to be
> interpreted by PHP rather than served as normal files.
> 
> If a webserver would not consider these files to be interpreted anymore
> this would have at least the following effects:
> - PHP web programs/sites no longer work
> - PHP files are directly exposed, which may be a security problem
> 
> 
> In order to avoid any problems, read the README.Debian from the
> php5-common package on how to correctly configure PHP (examples are
> provided for the Apache HTTPD Server) and take care, that and PHP files
> intended to be interpreted are recognised as such (typically by adding
> MIME-Type or handler definitions in the webserver configuration).
> 
> More information can be found in bug #674089 and partially in #674205.
> -------------------------------------------------------
> 
> As you can see, I personally would put the burden of explaining how to
> (securely) configure PHP to the PHP packages...
> I have some discussions about that with Ondřej in #674205 ... I'm not
> yet fully happy with it (see there)... and although he closed the bug
> and said he'd have applied some of my proposals, I could not yet find
> these changes there.

I think that the changes are the following:

-------------------------------------------------------------------------
index 26fe076..99c37c6 100644 (file)
--- a/debian/php5-common.README.Debian
+++ b/debian/php5-common.README.Debian
@@ -78,6 +78,11 @@ PHP 5 CGI and Apache HTTP Server
   installed side-by-side and both were automatically enabled, the
   results would be a bit confusing, obviously.
 
+  You should also be aware, that a server deployed in CGI mode is open
+  to several possible vulnerabilities, see upstream CGI security page
+  to learn ow to defend yourself from such attacks:
+  http://www.php.net/manual/en/security.cgi-bin.php
+
   To use php5-cgi with Apache HTTP Server:
   1) activate CGI (it's on by default in default debian setups)
      a) If using the prefork MPM, use 'a2enmod cgi'
@@ -86,8 +91,10 @@ PHP 5 CGI and Apache HTTP Server
   3) Add the following to a config snippet in /etc/apache2/conf.d
      <IfModule mod_actions.c>
        ScriptAlias /cgi-bin/php5-cgi /usr/lib/cgi-bin/php5
-       Action php5-cgi /cgi-bin/php5-cgi
-       AddHandler php5-cgi .php
+       Action application/x-php /cgi-bin/php5-cgi
+       <FilesMatch \.php$>
+         AddType application/x-php php
+       </FilesMatch>
      </IfModule>
 
   Note: more modern way of doing this is to install php5-fpm package
@@ -140,4 +147,4 @@ Further documentation, errata, misc.
   If after reading the documentation in this file you still have
   unanswered questions, that's a good next place to go.
 
- -- Ondřej Surý <ondrej@debian.org>, Sun,  8 Apr 2012 22:00:59 +0200
+ -- Ondřej Surý <ondrej@debian.org>, Mon,  6 Aug 2012 12:49:51 +0200
-------------------------------------------------------------------------


For the release note, I think that it would have to clearly indicate that this
only impacts the system running PHP scripts via the CGI package, which in my
understanding are the minority.

If upgrading to Wheezy would unconditionally break these systems, then I think
that a NEWS file in php5-cgi would be an important complement, as it would
interrupt the upgrades ran in standard conditions.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Information forwarded to debian-bugs-dist@lists.debian.org, Mime-Support Maintainers <mime-support@plessy.org>:
Bug#674089; Package mime-support. (Tue, 14 Aug 2012 00:30:03 GMT) (full text, mbox, link).

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Mime-Support Maintainers <mime-support@plessy.org>. (Tue, 14 Aug 2012 00:30:03 GMT) (full text, mbox, link).

Message #76 received at 674089@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Tue, 2012-08-14 at 08:06 +0900, Charles Plessy wrote: 
> +  You should also be aware, that a server deployed in CGI mode is open
> +  to several possible vulnerabilities, see upstream CGI security page
> +  to learn ow to defend yourself from such attacks:
> +  http://www.php.net/manual/en/security.cgi-bin.php
I doubt that this is a good idea,... to teach our users that the only
mode (CGI/FCGI) that can be made somehow secure from an operational
point of view, would be not.
With respect to the site you refer to:
The educated reader will quickly see, that 1/2 are simply about a
problem that the CGI interpreter _would_ read any files... and how to
prevent this.
Well... but it never does,... given that cgi.force_redirect is set.
(3) doc_root/user_dir should apply to the other SAPIs as well...
The same is true for (4)... if you are stupid enough to put your mod_php
libs into the web tree... well then no one can help you.

> +       Action application/x-php /cgi-bin/php5-cgi
> +       <FilesMatch \.php$>
> +         AddType application/x-php php
> +       </FilesMatch>
See my really elaborate discussion on how this should be securely set
(and how it can be optimised in contrast to the above) at the bug over
at php5-common, which I've mentioned several times now...
It get's boring to explain this over and over again,... honestly :(

> For the release note, I think that it would have to clearly indicate that this
> only impacts the system running PHP scripts via the CGI package,
This depends...
The mod_php packages ship their own, more or less secure (again, see my
bug at php5-common) config snippet for Apache (!), that already
registers it's own handler.
So mod_php/Apache = safe.
php-cgi = will be safe when the proposed steps are implemented.

Question: Can any other webservers use mod_php? If so, they _might_ be
vulnerable, as the supplied Apache config snippet probably doesn't apply
to them.

>  which in my
> understanding are the minority.
Do we really know? Most people I know run either CGI (if just security
counts) or FPM (if security and/or performance counts)...
And apart from that question, I don't think a minority deserved less
security, just because being a minority ;)

> If upgrading to Wheezy would unconditionally break these systems,
No,... this is not necessarily the case,.. if people have e.g. set their
own handlers/mime-times for php in apache.

As you can see... there is not a single scenario or case where problems
necessarily occur.
Which is why I proposed before to add this not only to the release
notes, but also to the NEWS files of php5-common and mime-types.

To be honest (and this is not meant against you, Charles), I'm quite
upset to see how things like this issue are handled.
First, a feeling for security seem to be missing, and if something is
not a typical attack on a binary, but insecurity on a higher level like
dangerous configuration, it seems to be not considered as security
problem.
People argue forth and back for weeks, whether some text is too much at
some place or whether a safety catch option at some place (that is not
required under normal circumstances but might protect under bad
situations) can be added per default or not.

In the meantime, all those using testing/sid may have some problems...
and in the real world, there are people using testing or even sid on
their servers.

Now I noticed that problem and fixed it on all my systems by deploying
secure and even optimised Apache configs, which I then suggested Ondrej
to add to his documentation for the benefit of all.
Again, a not yet ended discussion, which really feels like a pain in the
ar**.

Okay,... so much ranting from my side ;-)

But seriously,... I guess I've said what I'd do with respect to
release-notes/NEWS files several times now,... and also what I'd put
into php5-common for documentation and how I'd improve mod_php's default
config snippet.
So all I have to say is said... and unless someone has specific
technical questions, I'd like to back out from that discussion.

Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Acknowledgement sent to Charles Plessy <plessy@debian.org>:
Extra info received and forwarded to list. Copy sent to Mime-Support Maintainers <mime-support@plessy.org>. (Tue, 14 Aug 2012 00:54:03 GMT) (full text, mbox, link).

Message #81 received at 674089@bugs.debian.org (full text, mbox, reply):

Le Tue, Aug 14, 2012 at 02:27:33AM +0200, Christoph Anton Mitterer a écrit :
> 
> Question: Can any other webservers use mod_php? If so, they _might_ be
> vulnerable, as the supplied Apache config snippet probably doesn't apply
> to them.
 
> Most people I know run either CGI (if just security
> counts) or FPM (if security and/or performance counts)...
 
> > If upgrading to Wheezy would unconditionally break these systems,
> No,... this is not necessarily the case,.. if people have e.g. set their
> own handlers/mime-times for php in apache.

Hi again,

I have the following questions for the PHP maintainers.

1) Can libapache2-mod-php5 be vulnerable ?

2) The user base of php5-cgi is thousands (see Popcon URL below).  What feedback
   did you have from Sid and Wheezy users ?

   http://qa.debian.org/popcon-graph.php?packages=php5-cgi+libapache2-mod-php5&show_vote=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

3) Will upgrading unconditionally break sites using php5-cgi with Apache ?

4) Would you like to implement some of Christoph's suggestion or add a NEWs file to php5-cgi ?

On mime-support's side, I will not add a NEWs file, as it would interrupt the
installation of tens of thousands of systems which do not run PHP.

After your answer, I propose to send a brief summary to debian-release and
debian-devel, proposing reassign the bug to the release notes with the same
severity.

Have a nice day,

-- 
Charles Plessy
Co-maintainer of the mime-support package
Tsurumi, Kanagawa, Japan

Acknowledgement sent to Ondřej Surý <ondrej@debian.org>:
Extra info received and forwarded to list. Copy sent to Mime-Support Maintainers <mime-support@plessy.org>. (Tue, 14 Aug 2012 07:54:03 GMT) (full text, mbox, link).

Message #86 received at 674089@bugs.debian.org (full text, mbox, reply):

Charles,

On Tue, Aug 14, 2012 at 2:50 AM, Charles Plessy <plessy@debian.org> wrote:
> Le Tue, Aug 14, 2012 at 02:27:33AM +0200, Christoph Anton Mitterer a écrit :
>>
>> Question: Can any other webservers use mod_php? If so, they _might_ be
>> vulnerable, as the supplied Apache config snippet probably doesn't apply
>> to them.
>
>> Most people I know run either CGI (if just security
>> counts) or FPM (if security and/or performance counts)...
>
>> > If upgrading to Wheezy would unconditionally break these systems,
>> No,... this is not necessarily the case,.. if people have e.g. set their
>> own handlers/mime-times for php in apache.
>
> Hi again,
>
> I have the following questions for the PHP maintainers.
>
> 1) Can libapache2-mod-php5 be vulnerable ?

I don't think so. And from my testing it doesn't seem to be the case.

> 2) The user base of php5-cgi is thousands (see Popcon URL below).  What feedback
>    did you have from Sid and Wheezy users ?
>
>    http://qa.debian.org/popcon-graph.php?packages=php5-cgi+libapache2-mod-php5&show_vote=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

None.

> 3) Will upgrading unconditionally break sites using php5-cgi with Apache ?

Probably.

> 4) Would you like to implement some of Christoph's suggestion or add a NEWs file to php5-cgi ?

Yes, I will probably add NEWS file to php5-cgi. Do you already have some
text which can be added to release notes or we still need to cook something
up? I would like to keep this text in sync.

> On mime-support's side, I will not add a NEWs file, as it would interrupt the
> installation of tens of thousands of systems which do not run PHP.

Understood.

> After your answer, I propose to send a brief summary to debian-release and
> debian-devel, proposing reassign the bug to the release notes with the same
> severity.

Will you take care of that?

O.
-- 
Ondřej Surý <ondrej@sury.org>

Acknowledgement sent to Charles Plessy <plessy@debian.org>:
Extra info received and forwarded to list. Copy sent to Mime-Support Maintainers <mime-support@plessy.org>. (Wed, 15 Aug 2012 00:03:11 GMT) (full text, mbox, link).

Message #91 received at 674089@bugs.debian.org (full text, mbox, reply):

Hi Ondřej,

> On Tue, Aug 14, 2012 at 2:50 AM, Charles Plessy <plessy@debian.org> wrote:
> 
> Yes, I will probably add NEWS file to php5-cgi. Do you already have some
> text which can be added to release notes or we still need to cook something
> up? I would like to keep this text in sync.

For the moment there is the draft proposed by Christoph at http://bugs.debian.org/674089#66

-------------------------------------------------------
mime-types package dropped non-standard definitions for PHP that might
affect any systems using PHP
---
The package mime-types has dropped the following non-standard
definitions:
application/x-httpd-php                        phtml pht php
application/x-httpd-php-source                 phps
application/x-httpd-php3                       php3
application/x-httpd-php3-preprocessed          php3p
application/x-httpd-php4                       php4
application/x-httpd-php5                       php5

Systems, especially webservers (including but possibly not limited to
the Apache HTTPD Server) may have used this to mark files as having the
a PHP Internet Media Type (commonly known as MIME type).
They may have used it further, to determine that such files are to be
interpreted by PHP rather than served as normal files.

If a webserver would not consider these files to be interpreted anymore
this would have at least the following effects:
- PHP web programs/sites no longer work
- PHP files are directly exposed, which may be a security problem

In order to avoid any problems, read the README.Debian from the
php5-common package on how to correctly configure PHP (examples are
provided for the Apache HTTPD Server) and take care, that and PHP files
intended to be interpreted are recognised as such (typically by adding
MIME-Type or handler definitions in the webserver configuration).

More information can be found in bug #674089 and partially in #674205.
-------------------------------------------------------

Once we have a final text, and once you have added a NEWS file to php5-cgi (or
decided to not do so), I will take care of doublechecking on debian-devel and
debian-release that there is a rough consensus for our approach.

By the way, may I ask you a favor ?

In http://bugs.debian.org/661240, filed on mime-support, a user reported that
the upgrade broke his installation of WorPpress in a strange way, where only
some PHP files are executed and others are displayed as source code.  I can't
understand why such a thing would happen, so I do not know what to answer him.
Do you have a suggestion ?

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Message #96 received at 674089@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Wed, 2012-08-15 at 09:02 +0900, Charles Plessy wrote:
> For the moment there is the draft proposed by Christoph at http://bugs.debian.org/674089#66
I should note perhaps, that this draft expected all the proposals I made
in #674205 to be in place, which they were not yet, when I've looked the
last time.
So additions might needed to be made.


C.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Acknowledgement sent to Ondřej Surý <ondrej@debian.org>:
Extra info received and forwarded to list. Copy sent to Mime-Support Maintainers <mime-support@plessy.org>. (Wed, 15 Aug 2012 08:45:03 GMT) (full text, mbox, link).

Message #101 received at 674089@bugs.debian.org (full text, mbox, reply):

On Wed, Aug 15, 2012 at 4:34 AM, Christoph Anton Mitterer
<calestyo@scientia.net> wrote:
> On Wed, 2012-08-15 at 09:02 +0900, Charles Plessy wrote:
>> For the moment there is the draft proposed by Christoph at http://bugs.debian.org/674089#66
> I should note perhaps, that this draft expected all the proposals I made
> in #674205 to be in place, which they were not yet, when I've looked the
> last time.

With the exception of RemoteType php they are all in the place.

Thanks for the text, I will use it as a base for NEWS in php5-cgi.

This is the final text which I have commited to git repository:

php5 (5.4.4-5) unstable; urgency=low

 Please be aware that mime-types package dropped non-standard
 definitions for PHP that might affect any systems using PHP 5
 running as CGI or FastCGI.

 The package mime-types has dropped the following non-standard
 definitions:

  application/x-httpd-php                        phtml pht php
  application/x-httpd-php-source                 phps
  application/x-httpd-php3                       php3
  application/x-httpd-php3-preprocessed          php3p
  application/x-httpd-php4                       php4
  application/x-httpd-php5                       php5

 Systems, especially webservers (including but possibly not limited to
 the Apache HTTPD Server) may have used this to mark files as having
 the a PHP Internet Media Type (commonly known as MIME type).  They
 may have used it further, to determine that such files are to be
 interpreted by PHP rather than served as normal files.

 If a webserver would not consider these files to be interpreted
 anymore this would have at least the following effects:
  - PHP web programs/sites no longer work as expected
  - PHP files might be directly exposed, which may be a security
    problem

 In order to avoid any problems when not using Apache PHP5 module, and
 if you relied on MIME type definitions, read the README.Debian from
 the php5-common package on how to correctly configure PHP 5 running
 as a CGI or FastCGI (examples are provided for the Apache HTTPD
 Server) and take care, that and PHP files intended to be interpreted
 are recognised as such (typically by adding MIME-Type or handler
 definitions in the webserver configuration).

 -- Ondřej Surý <ondrej@debian.org>  Wed, 15 Aug 2012 10:31:31 +0200

O.
-- 
Ondřej Surý <ondrej@sury.org>

Acknowledgement sent to Stefan Fritsch <sf@debian.org>:
Extra info received and forwarded to list. Copy sent to Mime-Support Maintainers <mime-support@plessy.org>. (Wed, 15 Aug 2012 19:09:03 GMT) (full text, mbox, link).

Message #106 received at 674089@bugs.debian.org (full text, mbox, reply):

Thanks for coming up with some wording.

On Wednesday 15 August 2012, Ondřej Surý wrote:
>  In order to avoid any problems when not using Apache PHP5 module,
> and if you relied on MIME type definitions, read the README.Debian
> from the php5-common package on how to correctly configure PHP 5
> running as a CGI or FastCGI (examples are provided for the Apache
> HTTPD Server) and take care, that and PHP files intended to be
> interpreted are recognised as such (typically by adding MIME-Type
> or handler definitions in the webserver configuration).

Since we have gone to great pains to not use the magic MIME types 
anymore, I think we should not recommend them here. Or at least not as 
the first option.

Also, there is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670945 
to take into account. Is the wording still ok if the solution I 
suggested is implemented?

Message #111 received at 674089@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Wed, 2012-08-15 at 10:40 +0200, Ondřej Surý wrote:
> With the exception of RemoteType php they are all in the place.
I've just had a look into git (I guess that's the canonical location?):
http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=blob_plain;f=debian/php5-common.README.Debian;hb=HEAD
and
http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=blob_plain;f=debian/libapache2-mod-php5.conf;hb=HEAD

Even, if you don't want to add RemoveType to secure things more,... the
optimisations with respect to patterns and FilesMatch I've proposed
before and after you closed the other bug seem to miss completely.
Just in case this is by accident....


>  Please be aware that mime-types package dropped non-standard
cosmetic: a "the" is missing before mime-types

>  The package mime-types has dropped the following non-standard
>  definitions:
Seems to double the information from above a bit... I don't mind,.. just
you want to make it shorter :)


>  the a PHP Internet Media Type (commonly known as MIME type).  They
Typo: I guess that's from me ;-) ... the "a" is too much.



>  In order to avoid any problems when not using Apache PHP5 module
I don't like this negative advertising against the other SAPIs... :(


>  the php5-common package on how to correctly configure PHP 5 running
purely cosmetic: sometimes you/we write PHP5 sometimes PHP 5.


>  Server) and take care, that and PHP files intended to be interpreted
Typo: (also from me I guess?) the "and" seems to be too much, or
something is missing




Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #116 received at 674089@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Wed, 2012-08-15 at 21:07 +0200, Stefan Fritsch wrote:
> Since we have gone to great pains to not use the magic MIME types 
> anymore, I think we should not recommend them here. Or at least not as 
> the first option.
Stefan, can you please elaborate on what you mean with magic MIME types?
(you're talking about MIME type discovery via libmagic or similar? That
would be not what's suggested above!)


Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #121 received at 674089@bugs.debian.org (full text, mbox, reply):

On Wednesday 15 August 2012, Christoph Anton Mitterer wrote:
> On Wed, 2012-08-15 at 21:07 +0200, Stefan Fritsch wrote:
> > Since we have gone to great pains to not use the magic MIME types
> > anymore, I think we should not recommend them here. Or at least
> > not as the first option.
> 
> Stefan, can you please elaborate on what you mean with magic MIME
> types? (you're talking about MIME type discovery via libmagic or
> similar? That would be not what's suggested above!)

The mime types that are also handler names and cause mod_php to 
execute scripts, i.e. application/x-httpd-php and application/x-httpd-
php-source. Using these as mime types is dangerous because they may 
also cause things named like foo.php.bar to be executed.

Message #126 received at 674089@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Thu, 2012-08-16 at 00:24 +0200, Stefan Fritsch wrote:
> > Stefan, can you please elaborate on what you mean with magic MIME
> > types? (you're talking about MIME type discovery via libmagic or
> > similar? That would be not what's suggested above!)
> 
> The mime types that are also handler names and cause mod_php to 
> execute scripts, i.e. application/x-httpd-php and application/x-httpd-
> php-source. Using these as mime types is dangerous because they may 
> also cause things named like foo.php.bar to be executed.

Well the same is (IIRC) the case when you use handlers? No?

Anyway,... the configuration snippets I proposed in #674205 are _NOT_
vulnerable to the issue you describe, even though using AddType.
btw: I've emphasised this several times already,...

Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Mime-Support Maintainers <mime-support@plessy.org>:
Bug#674089; Package mime-support. (Thu, 16 Aug 2012 23:03:03 GMT) (full text, mbox, link).

Acknowledgement sent to Charles Plessy <plessy@debian.org>:
Extra info received and forwarded to list. Copy sent to Mime-Support Maintainers <mime-support@plessy.org>. (Thu, 16 Aug 2012 23:03:03 GMT) (full text, mbox, link).

Message #131 received at 674089@bugs.debian.org (full text, mbox, reply):

Le Thu, Aug 16, 2012 at 01:14:58AM +0200, Christoph Anton Mitterer a écrit :
> On Thu, 2012-08-16 at 00:24 +0200, Stefan Fritsch wrote:
> > > Stefan, can you please elaborate on what you mean with magic MIME
> > > types? (you're talking about MIME type discovery via libmagic or
> > > similar? That would be not what's suggested above!)
> > 
> > The mime types that are also handler names and cause mod_php to 
> > execute scripts, i.e. application/x-httpd-php and application/x-httpd-
> > php-source. Using these as mime types is dangerous because they may 
> > also cause things named like foo.php.bar to be executed.
> 
> Well the same is (IIRC) the case when you use handlers? No?
> 
> Anyway,... the configuration snippets I proposed in #674205 are _NOT_
> vulnerable to the issue you describe, even though using AddType.
> btw: I've emphasised this several times already,...

Dear all,

is the following summary accurate ?

 - In Squeeze, using default configurations, files with ".php" in their name
   such as "foo.php.jpeg" are executed as PHP scripts by the Apache web server.

 - To solve that problem, the media (MIME) type for PHP has been removed from
   /etc/mime.types (http://bugs.debian.org/589384).

 - This breaks the websites executing PHP scripts through php5-cgi, and
   a solution will be documented in the php5 package's NEWS file, and
   the same text will be proposed to the release notes (http://bugs.debian.org/674089,
   work in progress).

 - Unfortunately, the proposed solution exposes these websites to the original
   problem that caused the PHP media types to be removed from /etc/mime.types.


If the last point is true, I wonder how the other distributions are solving it,
given that in Fedora and Ubuntu, /etc/mime.types also does not contain the PHP
media types.  Can somebody investigate ?  I think that I do not understand the
problem well enough to be that person.


Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Mime-Support Maintainers <mime-support@plessy.org>. (Thu, 16 Aug 2012 23:57:03 GMT) (full text, mbox, link).

Message #136 received at 674089@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Fri, 2012-08-17 at 08:00 +0900, Charles Plessy wrote:
>  - In Squeeze, using default configurations, files with ".php" in their name
>    such as "foo.php.jpeg" are executed as PHP scripts by the Apache web server.
Looking at mod-php5 5.3.3-7+squeeze14:
not vulnerable, but not optimised either

PHP5 with CGI _is_ vulnerable, when (only) the configuration as
described in php5-common's README.Debian was followed.
The latter doesn't defined it's own mime-type or handler for .php files,
therefore the ones from mime-types are (likely) to be used, therefore
vulnerable to the foo.php.jpeg issue.


>  - To solve that problem, the media (MIME) type for PHP has been removed from
>    /etc/mime.types (http://bugs.debian.org/589384).
Seems so (*). That bug btw. is just THE justification for my demand to
add a RemoveType ... if that would have been in place, the mime-types
entries wouldn't have caused the foo.php.jpeg security issue (with the
<FilesMatch "\.ph(p3?|tml)$">  or an optimised version of that).

But I guess another reason should have been, that these pseudo types
should have never been there.


>  - This breaks the websites executing PHP scripts through php5-cgi, and
>    a solution will be documented in the php5 package's NEWS file, and
>    the same text will be proposed to the release notes (http://bugs.debian.org/674089,
>    work in progress).
Guess so.


>  - Unfortunately, the proposed solution exposes these websites to the original
>    problem that caused the PHP media types to be removed from /etc/mime.types.
No (well partially). As I told just in the mail you replied to (*feeling
a bit annoyed*)... neither what Ondřej uses now (version 5.4.4-4) in the
mod_php package's php5.conf:
    <FilesMatch "\.ph(p3?|tml)$">
	SetHandler application/x-httpd-php
    </FilesMatch>
    <FilesMatch "\.phps$">
	SetHandler application/x-httpd-php-source
    </FilesMatch>

nor what he wrote in README.Debian for CGI:
       <FilesMatch \.php$>
         AddType application/x-php php
       </FilesMatch>


are vulnerable, to the actual problem. They are though vulnerable to
exactly what we talked above at (*), because Ondřej refuses to add the
one line RemoveType.


And the same is true for the optimised versions (for both mod_php and
CGI) of the above I proposed in #674205, but which I guess won't be
merged either.


> If the last point is true
The reasons for that being not true it the
<FilesMatch "\.php$"> or in my optimised versions <Files ?*.php>
sections, wrapping around the SetHandler or AddType.
They ensure, that the handler or MIME type is only set for files
matching these patterns.
And files like foo.php.jpeg won't. In the slower FilesMatch version the
"$" in the end of the pattern is crucial for this to work.


Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Acknowledgement sent to Charles Plessy <plessy@debian.org>:
Extra info received and forwarded to list. Copy sent to Mime-Support Maintainers <mime-support@plessy.org>. (Sun, 19 Aug 2012 02:30:03 GMT) (full text, mbox, link).

Message #141 received at 674089@bugs.debian.org (full text, mbox, reply):

Dear all,

thanks everybody for your patience.  I know how frustrating it is when one
discussion has to be restarted from scratch because of newcommers.

I understand that Christoph is not satisfied about the final implementation
and, in his opinion, a lack of optimisation, but I cannot comment on that part
and I think it should be the topic of a separate bug if that discussion has to
continue.

As far as the mime-support package is concerned, I think that we reached the
consensus that we will not add the entries back, and that the consequences will
be documented in the php5-cgi package's NEWS file and in the release notes.

I have asked for comments about our current strategy on debian-devel and debian-release.

http://lists.debian.org/msgid-search/20120819021726.GC20875@falafel.plessy.net

Have a nice Sunday,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Acknowledgement sent to Ondřej Surý <ondrej@debian.org>:
Extra info received and forwarded to list. Copy sent to Mime-Support Maintainers <mime-support@plessy.org>. (Mon, 20 Aug 2012 13:00:09 GMT) (full text, mbox, link).

Message #146 received at 674089@bugs.debian.org (full text, mbox, reply):

Hi all,

[multiple messages from d-d and d-r merged together]

> I am also concerned that a *simple* solution to restore the old
> behaviour in a secure way is not provided: maybe php5-cgi should install
> a sensible default configuration in /etc/apache2/conf.d/ ?

I have prepared new update for PHP based on comments from d-d. The
commit is here:

http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=commit;h=72eef08994f65b227103509617652d7c0bf0587a

To sum the changes:

- create dummy php5_cgi module, which has the required configuration inside
- enable this module if upgrading from anything older than 5.4.4-5
- the module is not enabled on fresh installs (user has to enable it manually)
- update NEWS.Debian to:

php5 (5.4.4-5) unstable; urgency=low

 Please be aware that the mime-types package dropped non-standard
 definitions for PHP that might affect any systems using PHP 5 running
 as CGI or FastCGI.  Following definitions were dropped:

  application/x-httpd-php                        phtml pht php
  application/x-httpd-php-source                 phps
  application/x-httpd-php3                       php3
  application/x-httpd-php3-preprocessed          php3p
  application/x-httpd-php4                       php4
  application/x-httpd-php5                       php5

 The php5-cgi package mitigates any known issues by creating a (dummy)
 apache2 module php5_cgi with a configuration containing handlers for
 all previously defined extensions.  Even though we believe that this
 configuration should keep your PHP scripts interpreted, it might be a
 good idea to check your apache2 site-wide configuration and also any
 specific PHP configuration for websites running on your system.

 As far as we know definitions from the mime-types packages are not
 used in any other webserver included in Debian, but it might affect
 any application which relies on system MIME types to interpret PHP
 files.

 -- Ondřej Surý <ondrej@debian.org>  Wed, 15 Aug 2012 10:31:31 +0200

- Update the README.Debian to match current state.

I will upload this change as part of 5.4.6-1 upload to Debian experimental
and if everything is ok, I'll merge it back to 5.4.4-5 targeted to
unstable->testing.

> As far as the mime-support package is concerned, I think that we reached the
> consensus that we will not add the entries back, and that the consequences will
> be documented in the php5-cgi package's NEWS file and in the release notes.

I agree on that, even though I think that PHP should have it's own
mimetype definition (same as python or perl, e.g. application/x-php,
but let's keep this discussion out of this issue, since it's something
different).

> I guess we could consider that for a very specific, low-popcon package.
> But knowingly interrupting upgrades for a well-known problem, on a very
> high number of systems? I'm not sure that's appropriate. Quite the
> opposite, actually.

I believe that update that I just did should solve any backwards
compatibility issues. (Crossed fingers... have to do thourough testing
first, I tend to make mistakes from time to time.)

> Many of the users of php5-cgi will be doing so because they are using other
> web servers. The discussion in #674089 seems to mainly revolve around
> Apache. How does this affect other web servers?

I am not aware of any other (Debian shipped) web server which uses
system-wide mime-types.  At least both nginx and lighttpd don't depend
on system mime types for interpreting PHP files (both use extension
based definitions).

>  - In Squeeze, using default configurations, files with ".php" in their name
>    such as "foo.php.jpeg" are executed as PHP scripts by the Apache web servers
>    runing PHP scripts through php5-cgi.

Charles, did you test that or you base that claim on Christoph's
mails?  I have just tested both php5-cgi in standard configuration as
recommended in README.Debian and this claim doesn't seem to be true:

$ wget -q -O - http://localhost:8080/index.php
bar
$ wget -q -O - http://localhost:8080/index.php.jpeg
<?php echo 'foo'; ?>

Also Apache2 documentation is very clear on that issue:
See http://httpd.apache.org/docs/2.2/mod/mod_mime.html#multipleext

> If more than one extension is given that maps onto the same type of meta-information, then the one to the right will be used, except for languages and content encodings. For example, if .gif maps to the MIME-type image/gif and .html maps to the MIME-type text/html, then the file welcome.gif.html will be associated with the MIME-type text/html.

However there could be a problem when you use MIME-type and handler
together (which we *don't* use):

> Care should be taken when a file with multiple extensions gets associated with both a MIME-type and a handler. This will usually result in the request being handled by the module associated with the handler.

> Maybe that's because it's expected they would be PHP scripts emitting
> JPEG files, not plain JPEG files? This seems like a feature to me, not a
> bug. Why was support for that removed?

My testing shows that the support for this was NEVER there in the
first place; neither in php5-cgi nor in libapache2-mod-php5. (Unless
you have jumped through some loops and used custom configuration not
recommended by upstream - in that case you will also probably have a
configuration which overrides our configuration anyway.)

O.
P.S.: Ccing me or pkg-php-maint increases the change I will see the
message and reply to you.
-- 
Ondřej Surý <ondrej@sury.org>

Acknowledgement sent to Charles Plessy <plessy@debian.org>:
Extra info received and forwarded to list. Copy sent to Mime-Support Maintainers <mime-support@plessy.org>. (Mon, 20 Aug 2012 13:39:03 GMT) (full text, mbox, link).

Message #151 received at 674089@bugs.debian.org (full text, mbox, reply):

Le Mon, Aug 20, 2012 at 02:57:10PM +0200, Ondřej Surý a écrit :
> 
> I have prepared new update for PHP based on comments from d-d. The
> commit is here:
> 
> http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=commit;h=72eef08994f65b227103509617652d7c0bf0587a

Hi Ondřej,

many thanks for this work.

> Charles, did you test that or you base that claim on Christoph's
> mails?  I have just tested both php5-cgi in standard configuration as
> recommended in README.Debian and this claim doesn't seem to be true:
> 
> $ wget -q -O - http://localhost:8080/index.php
> bar
> $ wget -q -O - http://localhost:8080/index.php.jpeg
> <?php echo 'foo'; ?>

I did not test, and was trusting from http://bugs.debian.org/589384, which
requested the removal of the PHP media types for Wheezy, that the problem was
still present in some configurations.

Good to see that we are heading towards a solution anyway.

What shall I do with #674089 ?  I can reassign it to php5-cgi so that your next
upload closes it, or do we still need release notes ?

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Acknowledgement sent to Ondřej Surý <ondrej@debian.org>:
Extra info received and forwarded to list. Copy sent to Mime-Support Maintainers <mime-support@plessy.org>. (Mon, 20 Aug 2012 13:51:03 GMT) (full text, mbox, link).

Message #156 received at 674089@bugs.debian.org (full text, mbox, reply):

On Mon, Aug 20, 2012 at 3:35 PM, Charles Plessy <plessy@debian.org> wrote:
>> Charles, did you test that or you base that claim on Christoph's
>> mails?  I have just tested both php5-cgi in standard configuration as
>> recommended in README.Debian and this claim doesn't seem to be true:
>>
>> $ wget -q -O - http://localhost:8080/index.php
>> bar
>> $ wget -q -O - http://localhost:8080/index.php.jpeg
>> <?php echo 'foo'; ?>
>
> I did not test, and was trusting from http://bugs.debian.org/589384, which
> requested the removal of the PHP media types for Wheezy, that the problem was
> still present in some configurations.

Ah, I see; it gets executed when there is no know handler or mime-type
for second extension.

E.g. index.php.jpeg works as expected (e.g. returning PHP source
code), index.php.blubb but gets executed. I don't think there's any
harm in disabling php.foobar and php.blubb files.

> Good to see that we are heading towards a solution anyway.
>
> What shall I do with #674089 ?  I can reassign it to php5-cgi so that your next
> upload closes it, or do we still need release notes ?

I think we still might need release notes, but it needs to be updated
based on final impact of changes we have done. I am not sure if the
information about <filename>.php.<unknown-mime-type> is worth release
notes or just NEWS file in PHP. My guess would be latter, but opinions
may vary.

Also I am not happy that we make these changes so late in release
cycle, but I guess we now have to find a way how to cope with them and
still make release team happy. I think the changes I have done are
least intrusive, but again opinions may vary.

O.
-- 
Ondřej Surý <ondrej@sury.org>

Acknowledgement sent to Stefan Fritsch <sf@debian.org>:
Extra info received and forwarded to list. Copy sent to Mime-Support Maintainers <mime-support@plessy.org>. (Mon, 20 Aug 2012 18:15:03 GMT) (full text, mbox, link).

Message #161 received at 674089@bugs.debian.org (full text, mbox, reply):

On Monday 20 August 2012, Ondřej Surý wrote:
> Ah, I see; it gets executed when there is no know handler or
> mime-type for second extension.
> 
> E.g. index.php.jpeg works as expected (e.g. returning PHP source
> code), index.php.blubb but gets executed. I don't think there's any
> harm in disabling php.foobar and php.blubb files.

There is also the case that the extensions after .php are known to 
Apache but are not associated with mime types or handlers. For 
example, there are extensions like .de and .en which cause the 
Content-Language header to be set, extensions for setting the charset 
(e.g. .utf8) and extensions for setting the content-encoding (none 
configured by default).

I don't know how often this is actually used together with php. 
Setting the Content-* headers in the php script seems saner to me.

> > Good to see that we are heading towards a solution anyway.
> > 
> > What shall I do with #674089 ?  I can reassign it to php5-cgi so
> > that your next upload closes it, or do we still need release
> > notes ?
> 
> I think we still might need release notes, but it needs to be
> updated based on final impact of changes we have done. I am not
> sure if the information about <filename>.php.<unknown-mime-type>
> is worth release notes or just NEWS file in PHP. My guess would be
> latter, but opinions may vary.

Maybe add just a small paragraph that the configuration of the 
extensions has changed and php users should read the NEWS file?

Cheers,
Stefan

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Mime-Support Maintainers <mime-support@plessy.org>. (Mon, 20 Aug 2012 19:12:03 GMT) (full text, mbox, link).

Message #166 received at 674089@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi Ondřej.

On Mon, 2012-08-20 at 14:57 +0200, Ondřej Surý wrote:
> http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=commit;h=72eef08994f65b227103509617652d7c0bf0587a
- You mention in the README.Debian now, that no other webserver likely used /etc/mime.types.
Wasn't there someone who meant lighthttp was also using it?

- I like the changes to the wording of the "PHP 5 CGI and Apache HTTP
Server" section.

- Where you write: "add the mentioned configuration block to one or more
virtual sites." ... you may even refine that to "add the mentioned
configuration block to one or more virtual hosts or directories."

- Where you write: "It's advised to not mix&match mod_php and php5-cgi
in the same" is that intended, that php5-fpm is missing?


To the rules:
- They seem ok for a security point of view.
- When using FilesMatch, one can slightly optimise the subpatterns, by
placing "?:" after the "(", e.g.
".+\.ph(?:p[345]?|t|tml)$"
- At the places where you Deny, one might perhaps add "Satisfy All"
again. It's "All" per default, but if one has set that to Any in main
server context, your deny-intention might geht ineffective again.


> I agree on that, even though I think that PHP should have it's own
> mimetype definition (same as python or perl, e.g. application/x-php,
> but let's keep this discussion out of this issue, since it's something
> different).
+1 on that.


> I am not aware of any other (Debian shipped) web server which uses
> system-wide mime-types.  At least both nginx and lighttpd don't depend
> on system mime types for interpreting PHP files (both use extension
> based definitions).
Ah ok,... so ignore my question from above... :)


> > If more than one extension is given that maps onto the same type of
> meta-information, then the one to the right will be used, except for
> languages and content encodings. For example, if .gif maps to the
> MIME-type image/gif and .html maps to the MIME-type text/html, then
> the file welcome.gif.html will be associated with the MIME-type
> text/html.
Right, ....the others already pointed out in the meantime, what can
still happen.
I guess we should be largely safe of all this now.



Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #171 received at 674089@bugs.debian.org (full text, mbox, reply):

On Mon, Aug 20, 2012 at 8:12 PM, Stefan Fritsch <sf@debian.org> wrote:
> On Monday 20 August 2012, Ondřej Surý wrote:
>> Ah, I see; it gets executed when there is no know handler or
>> mime-type for second extension.
>>
>> E.g. index.php.jpeg works as expected (e.g. returning PHP source
>> code), index.php.blubb but gets executed. I don't think there's any
>> harm in disabling php.foobar and php.blubb files.
>
> There is also the case that the extensions after .php are known to
> Apache but are not associated with mime types or handlers. For
> example, there are extensions like .de and .en which cause the
> Content-Language header to be set, extensions for setting the charset
> (e.g. .utf8) and extensions for setting the content-encoding (none
> configured by default).
>
> I don't know how often this is actually used together with php.
> Setting the Content-* headers in the php script seems saner to me.

Right, I have never seen this to be used together with PHP, but it
probably deserves a note somewhere.

>> > Good to see that we are heading towards a solution anyway.
>> >
>> > What shall I do with #674089 ?  I can reassign it to php5-cgi so
>> > that your next upload closes it, or do we still need release
>> > notes ?
>>
>> I think we still might need release notes, but it needs to be
>> updated based on final impact of changes we have done. I am not
>> sure if the information about <filename>.php.<unknown-mime-type>
>> is worth release notes or just NEWS file in PHP. My guess would be
>> latter, but opinions may vary.
>
> Maybe add just a small paragraph that the configuration of the
> extensions has changed and php users should read the NEWS file?

That's probably sensible approach.  I have quickly drafted short
paragraph which can be used for release notes:

Default PHP extension configuration
-----------------------------------

The mime-types package has dropped non-standard definitions of
PHP MIME-Types as a security measure.  Default PHP configuration
for libapache2-mod-php5{filter} and php5-cgi now only serve files
which have .php, .php[345] and .phtml extensions on a most right
place as opposed to previous state where <filename>.php.foobar
would have been interpreted.  Please read NEWS file in the PHP
SAPI of your choice for further information.


---

O.
-- 
Ondřej Surý <ondrej@sury.org>

Message #176 received at 674089@bugs.debian.org (full text, mbox, reply):

> Default PHP extension configuration

^^^
This needs Apache 2, e.g.

Default PHP extension configuration for Apache 2.

> -----------------------------------
>
> The mime-types package has dropped non-standard definitions of
> PHP MIME-Types as a security measure.  Default PHP configuration
> for libapache2-mod-php5{filter} and php5-cgi now only serve files
> which have .php, .php[345] and .phtml extensions on a most right
> place as opposed to previous state where <filename>.php.foobar
> would have been interpreted.  Please read NEWS file in the PHP
> SAPI of your choice for further information.

O.
-- 
Ondřej Surý <ondrej@sury.org>

Acknowledgement sent to Konstantin Khomoutov <flatworm@users.sourceforge.net>:
Extra info received and forwarded to list. Copy sent to Mime-Support Maintainers <mime-support@plessy.org>. (Tue, 21 Aug 2012 07:48:03 GMT) (full text, mbox, link).

Message #181 received at 674089@bugs.debian.org (full text, mbox, reply):

On Tue, Aug 21, 2012 at 09:07:59AM +0200, Ondřej Surý wrote:

[...]
>> Maybe add just a small paragraph that the configuration of the
>> extensions has changed and php users should read the NEWS file?
> 
> That's probably sensible approach.  I have quickly drafted short
> paragraph which can be used for release notes:
> 
> Default PHP extension configuration
> -----------------------------------
> 
> The mime-types package has dropped non-standard definitions of
> PHP MIME-Types as a security measure.  Default PHP configuration
> for libapache2-mod-php5{filter} and php5-cgi now only serve files
> which have .php, .php[345] and .phtml extensions on a most right
> place as opposed to previous state where <filename>.php.foobar
> would have been interpreted.  Please read NEWS file in the PHP
> SAPI of your choice for further information.

I fail to parse that "on a most right place" bit though I'm not a native
speaker.  If you meant that those extension specifications form a minimal
sane and safe subset, may be just go ahead and write exactly that. ;-)

Message #186 received at 674089@bugs.debian.org (full text, mbox, reply):

On Tue, Aug 21, 2012 at 9:38 AM, Konstantin Khomoutov
<flatworm@users.sourceforge.net> wrote:
> On Tue, Aug 21, 2012 at 09:07:59AM +0200, Ondřej Surý wrote:
>
> [...]
>>> Maybe add just a small paragraph that the configuration of the
>>> extensions has changed and php users should read the NEWS file?
>>
>> That's probably sensible approach.  I have quickly drafted short
>> paragraph which can be used for release notes:
>>
>> Default PHP extension configuration
>> -----------------------------------
>>
>> The mime-types package has dropped non-standard definitions of
>> PHP MIME-Types as a security measure.  Default PHP configuration
>> for libapache2-mod-php5{filter} and php5-cgi now only serve files
>> which have .php, .php[345] and .phtml extensions on a most right
>> place as opposed to previous state where <filename>.php.foobar
>> would have been interpreted.  Please read NEWS file in the PHP
>> SAPI of your choice for further information.
>
> I fail to parse that "on a most right place" bit though I'm not a native
> speaker.  If you meant that those extension specifications form a minimal
> sane and safe subset, may be just go ahead and write exactly that. ;-)

Nope I mean that the extension should be last.

E.g.  index.blah.php, but not index.php.blah.

O.
-- 
Ondřej Surý <ondrej@sury.org>

Message #191 received at 674089@bugs.debian.org (full text, mbox, reply):

On Tue, 21 Aug 2012 09:48:37 +0200
Ondřej Surý <ondrej@debian.org> wrote:

[...]
> >> The mime-types package has dropped non-standard definitions of
> >> PHP MIME-Types as a security measure.  Default PHP configuration
> >> for libapache2-mod-php5{filter} and php5-cgi now only serve files
> >> which have .php, .php[345] and .phtml extensions on a most right
> >> place as opposed to previous state where <filename>.php.foobar
> >> would have been interpreted.  Please read NEWS file in the PHP
> >> SAPI of your choice for further information.
> >
> > I fail to parse that "on a most right place" bit though I'm not a
> > native speaker.  If you meant that those extension specifications
> > form a minimal sane and safe subset, may be just go ahead and write
> > exactly that. ;-)
> 
> Nope I mean that the extension should be last.
> 
> E.g.  index.blah.php, but not index.php.blah.
Thanks for the explanation.

Then I suggest it to be rephrased "... extensions on the rightmost
place ...", or may be even simpler: "... php5-cgi now only serves files
which have .php, .php[345] or .phtml as their rightmost extension ...".

Acknowledgement sent to Philip Hands <phil@hands.com>:
Extra info received and forwarded to list. Copy sent to Mime-Support Maintainers <mime-support@plessy.org>. (Tue, 21 Aug 2012 10:51:03 GMT) (full text, mbox, link).

Message #196 received at 674089@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Konstantin Khomoutov <flatworm@users.sourceforge.net> writes:
...
> Then I suggest it to be rephrased "... extensions on the rightmost
> place ...", or may be even simpler: "... php5-cgi now only serves files
> which have .php, .php[345] or .phtml as their rightmost extension
> ...".

how about "... have .php, .php[345] or .phtml at the end"?

(or 'right-hand end' if you think there's any possibility of confusion)

'extension' only really makes sense on FAT and similar file systems, and
the extension on those file systems does not include the full-stop (.)

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]    http://www.hands.com/
|-|  HANDS.COM Ltd.                    http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND

[Message part 2 (application/pgp-signature, inline)]

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Mime-Support Maintainers <mime-support@plessy.org>. (Tue, 21 Aug 2012 23:39:03 GMT) (full text, mbox, link).

Message #201 received at 674089@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Tue, 2012-08-21 at 09:07 +0200, Ondřej Surý wrote:
> > Maybe add just a small paragraph that the configuration of the
> > extensions has changed and php users should read the NEWS file?
> 
> That's probably sensible approach.  I have quickly drafted short
> paragraph which can be used for release notes:
Sounds good...

> which have .php, .php[345] and .phtml extensions on a most right
> place 
May I suggest to add "for security reasons" in the end?
I guess we all agreed that deliberately using "foo.php.jpeg" is in most
cases dangerous and bad style, too,... so why not teach our users a
bit?! :-)


On Tue, 2012-08-21 at 09:48 +0200, Ondřej Surý wrote:
> Nope I mean that the extension should be last.
Perhaps use the phrase "rightmost extension", or "trailing extension"?
Or even give a short example?


Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Reply sent to Ondřej Surý <ondrej@sury.org>:
You have taken responsibility. (Thu, 23 Aug 2012 08:18:03 GMT) (full text, mbox, link).

Notification sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Bug acknowledged by developer. (Thu, 23 Aug 2012 08:18:03 GMT) (full text, mbox, link).

Message #206 received at 674089-done@bugs.debian.org (full text, mbox, reply):

Version: php5/5.4.4-5

This bug was fixed in php5/5.4.4-5.

O.
-- 
Ondřej Surý <ondrej@sury.org>

Reply sent to Ondřej Surý <ondrej@sury.org>:
You have taken responsibility. (Thu, 23 Aug 2012 08:18:03 GMT) (full text, mbox, link).

Notification sent to Jacopo Girardi <jacopogg83.os@libero.it>:
Bug acknowledged by developer. (Thu, 23 Aug 2012 08:18:04 GMT) (full text, mbox, link).

Disconnected #664691 from all other report(s). Request was from Ondřej Surý <ondrej@debian.org> to control@bugs.debian.org. (Thu, 23 Aug 2012 08:21:14 GMT) (full text, mbox, link).

Bug reassigned from package 'mime-support' to 'php5'. Request was from Charles Plessy <plessy@debian.org> to control@bugs.debian.org. (Sat, 25 Aug 2012 02:24:05 GMT) (full text, mbox, link).

No longer marked as found in versions mime-support/3.52-1 and mime-support/3.48-1. Request was from Charles Plessy <plessy@debian.org> to control@bugs.debian.org. (Sat, 25 Aug 2012 02:24:05 GMT) (full text, mbox, link).

Reply sent to Charles Plessy <plessy@debian.org>:
You have taken responsibility. (Sat, 25 Aug 2012 02:30:04 GMT) (full text, mbox, link).

Notification sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Bug acknowledged by developer. (Sat, 25 Aug 2012 02:30:04 GMT) (full text, mbox, link).

Message #221 received at 674089-done@bugs.debian.org (full text, mbox, reply):

Version: php5/5.4.4-5

As per http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674089#206

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sat, 22 Sep 2012 07:28:41 GMT) (full text, mbox, link).

Send a report that this bug log contains spam.

Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sun Jul 2 03:43:14 2023; Machine Name: bembo

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Debian Bug report logs - #674089 mime-support: removed application/x-httpd-* can lead to immense security problems

Debian Bug report logs - #674089
mime-support: removed application/x-httpd-* can lead to immense security problems