Bug#674089: [php-maint] Bug#674089: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
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.gc20...@falafel.plessy.net Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674089: [php-maint] Bug#674089: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674089: [php-maint] Bug#674089: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
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 Description: S/MIME cryptographic signature
Bug#674089: [php-maint] Bug#674089: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
On Wed, Aug 15, 2012 at 4:34 AM, Christoph Anton Mitterer cales...@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-phpphtml 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ý ond...@debian.org Wed, 15 Aug 2012 10:31:31 +0200 O. -- Ondřej Surý ond...@sury.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674089: [php-maint] Bug#674089: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
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? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674089: [php-maint] Bug#674089: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
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 Description: S/MIME cryptographic signature
Bug#674089: [php-maint] Bug#674089: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
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 Description: S/MIME cryptographic signature
Bug#674089: [php-maint] Bug#674089: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674089: [php-maint] Bug#674089: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
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 Description: S/MIME cryptographic signature
Bug#674089: [php-maint] Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
Charles, On Tue, Aug 14, 2012 at 2:50 AM, Charles Plessy ple...@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-php5show_vote=onfrom_date=to_date=hlght_date=date_fmt=%25Y-%25mbeenhere=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ý ond...@sury.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674089: [php-maint] Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
Hi Ondřej, On Tue, Aug 14, 2012 at 2:50 AM, Charles Plessy ple...@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-phpphtml 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674089: [php-maint] Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
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 Description: S/MIME cryptographic signature
Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
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-phpphtml 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ý ond...@debian.org, Sun, 8 Apr 2012 22:00:59 +0200 + -- Ondřej Surý ond...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
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 Description: S/MIME cryptographic signature
Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
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-php5show_vote=onfrom_date=to_date=hlght_date=date_fmt=%25Y-%25mbeenhere=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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
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-phpphtml 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 Description: S/MIME cryptographic signature
Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
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 Description: S/MIME cryptographic signature
Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
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-apa...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
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 Description: S/MIME cryptographic signature
Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
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 Description: OpenPGP digital signature
Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
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
Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
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 Description: S/MIME cryptographic signature
Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
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 Description: S/MIME cryptographic signature
Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
