Re: Possible release note for systems running PHP through CGI.
On Mon, Aug 20, 2012 at 8:12 PM, Stefan Fritsch s...@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ý ond...@sury.org
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CALjhHG_CqTNyOY2K8QwLk=yFAJ6JYKDvs9aRAjFUVGdYZCB=l...@mail.gmail.com
Re: Possible release note for systems running PHP through CGI.
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ý ond...@sury.org
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caljhhg_0smdoegerxyen1u0mxgpmyyt1gbvmqdmictt-u4e...@mail.gmail.com
Re: Possible release note for systems running PHP through CGI.
On Tue, Aug 21, 2012 at 9:38 AM, Konstantin Khomoutov
flatw...@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ý ond...@sury.org
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CALjhHG8-3XkmJK53qrHpJjvFBATpproJB�h5rk7pgksmj...@mail.gmail.com
Re: Possible release note for systems running PHP through CGI.
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. ;-)
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120821073858.GH1685@localhost.localdomain
Re: Possible release note for systems running PHP through CGI.
On Mon, Aug 20, 2012 at 03:12:14PM +0100, Steven Chamberlain wrote: On 20/08/12 14:35, Wouter Verhelst wrote: On Mon, Aug 20, 2012 at 01:10:57PM +0100, Steven Chamberlain wrote: Yes it's possible some people rely on that behaviour, e.g. serving JPEG data from PHP scripts named like foo.php.jpeg. Sorry, I was wrong. For extensions like .jpeg with a known MIME type it does not work. So, people are unlikely to be relying on this effect. http://lists.debian.org/caljhhg8dd+nv2uvgjbvrtubdna3m+o1afo0bqylyfpqkhuj...@mail.gmail.com But some sites accept file uploads with arbitrary names, [...] Don't Do That Then(TM). Yes I very much agree... [...] write your upload scripts so that they - Store uploads in a directory which is served by the webserver, but without allowing any kind of script execution (i.e., Options -ExecCGI and similar things for other scripting environments and/or webservers) I believe -ExecCGI would work for php5-cgi but not for libapache2-mod-php5 (whose handler relies on MIME types). I did say and similar things for other scripting environments for a reason... To protect against that, I notice our drupal6 packages create an .htaccess file in the file uploads directory, with: SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006 Yes. This is exactly what I described above: make sure the uploads are in a directory that disallows any kind of script execution. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120821090717.gb6...@grep.be
Re: Possible release note for systems running PHP through CGI.
On Mon, Aug 20, 2012 at 06:40:54PM +0200, Marco d'Itri wrote: On Aug 20, Wouter Verhelst w...@uter.be wrote: But some sites accept file uploads with arbitrary names, perhaps expected to be a JPEG image, but actually named bar.php.jpeg and containing malicious server-side PHP which they could execute from the browser. Don't Do That Then(TM). I see that you are not in the web hosting business. g Nope. But we can't do the job of a person running a shared hosting webserver, anyway, because the security issues in that area of business are so intense that people doing shared hosting for random crap code of their customers need to review and overhaul the default configuration in minute detail anyway. Again, if there's something we can do to make their jobs easier without impacting a significant amount of our other users, I'm all for it. I don't think this particular bit qualifies, however. Millions of web sites do this, so now matter how a bad practice this is (and I agree that it is) we need to do everything possible to work around insecure web sites. Yes, you (a person who maintains servers in a shared hosting business) need to do that. We (Debian) have different priorities, however. Also, we are talking about PHP: if educating developers were possible, they would not use PHP in the first place. *g* [...] -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120821091425.gc6...@grep.be
Re: Possible release note for systems running PHP through CGI.
On Tue, 21 Aug 2012 09:48:37 +0200
Ondřej Surý ond...@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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20120821135240.8966d86610134c36f300a...@domain007.com
Re: Possible release note for systems running PHP through CGI.
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 Description: S/MIME cryptographic signature
Re: Possible release note for systems running PHP through CGI.
On Sun, Aug 19, 2012 at 11:17:26AM +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 servers runing PHP scripts through php5-cgi. 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? -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120820070213.gb4...@grep.be
Re: Possible release note for systems running PHP through CGI.
On 20/08/12 08:02, Wouter Verhelst wrote: On Sun, Aug 19, 2012 at 11:17:26AM +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 servers runing PHP scripts through php5-cgi. 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? Yes it's possible some people rely on that behaviour, e.g. serving JPEG data from PHP scripts named like foo.php.jpeg. But some sites accept file uploads with arbitrary names, perhaps expected to be a JPEG image, but actually named bar.php.jpeg and containing malicious server-side PHP which they could execute from the browser. If that behaviour is changed, then where the PHP preprocessor was previously invoked because of the detected MIME type, it would now serve up the source code instead (leading to information disclosure). I imagine the 'safest' way to handle this is to preserve the original behaviour, still recognising *.php* as PHP scripts, but deny access to (through ACLs or a dummy handler) files containing .php. in their name, unless the filename actually ends in .php /If/ that could work, it would limit any disruption to the two cases where it might be a security issue. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50322951.30...@pyro.eu.org
Re: Possible release note for systems running PHP through CGI.
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-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 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ý ond...@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
Re: Possible release note for systems running PHP through CGI.
On Mon, Aug 20, 2012 at 12:58:42AM +0200, Christoph Anton Mitterer wrote: But if anyone would lobby that (release goal: default to CGI/FCGI), they'd have definitely my support :) A bit late for wheezy, do you mean for +1? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120820130646.GA28685@debian
Re: Possible release note for systems running PHP through CGI.
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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120820133509.gb6...@falafel.plessy.net
Re: Possible release note for systems running PHP through CGI.
On Mon, Aug 20, 2012 at 01:10:57PM +0100, Steven Chamberlain wrote: On 20/08/12 08:02, Wouter Verhelst wrote: On Sun, Aug 19, 2012 at 11:17:26AM +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 servers runing PHP scripts through php5-cgi. 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? Yes it's possible some people rely on that behaviour, e.g. serving JPEG data from PHP scripts named like foo.php.jpeg. But some sites accept file uploads with arbitrary names, perhaps expected to be a JPEG image, but actually named bar.php.jpeg and containing malicious server-side PHP which they could execute from the browser. Don't Do That Then(TM). There are APIs for many server-side languages, including PHP, that allow you to generate a filename for something a user uploads. If you rely on the name as specified by a user, you not only invite this kind of problems, but also directory traversals and similar things. Scripts not using those APIs are buggy scripts, plain and simple. Fixing those bugs should happen in the script, not by mucking about with the default webserver configuration. The right solution to this problem is instead to write your upload scripts so that they - Store uploads in a directory which is served by the webserver, but without allowing any kind of script execution (i.e., Options -ExecCGI and similar things for other scripting environments and/or webservers) - Use a server-generated filename, and throw away whatever the user sent. If you do still need the user-specified filename for some weird reason, then store it in a database. Alternatively, you could only allow trusted users to upload files (but obviously, that isn't always a solution). Writing secure code for the web is hard; fixing that isn't really possible. Now if some change were to make it possible to improve security without unnecessarily impacting things that actually matter, then I'd be all for it. But in this case, I'm not sure the benefits outweigh the costs. [...] -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120820133551.gb7...@grep.be
Re: Possible release note for systems running PHP through CGI.
On Mon, Aug 20, 2012 at 3:35 PM, Charles Plessy ple...@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ý ond...@sury.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caljhhg8dd+nv2uvgjbvrtubdna3m+o1afo0bqylyfpqkhuj...@mail.gmail.com
Re: Possible release note for systems running PHP through CGI.
On 20/08/12 14:35, Wouter Verhelst wrote: On Mon, Aug 20, 2012 at 01:10:57PM +0100, Steven Chamberlain wrote: Yes it's possible some people rely on that behaviour, e.g. serving JPEG data from PHP scripts named like foo.php.jpeg. Sorry, I was wrong. For extensions like .jpeg with a known MIME type it does not work. So, people are unlikely to be relying on this effect. http://lists.debian.org/caljhhg8dd+nv2uvgjbvrtubdna3m+o1afo0bqylyfpqkhuj...@mail.gmail.com But some sites accept file uploads with arbitrary names, [...] Don't Do That Then(TM). Yes I very much agree... [...] write your upload scripts so that they - Store uploads in a directory which is served by the webserver, but without allowing any kind of script execution (i.e., Options -ExecCGI and similar things for other scripting environments and/or webservers) I believe -ExecCGI would work for php5-cgi but not for libapache2-mod-php5 (whose handler relies on MIME types). To protect against that, I notice our drupal6 packages create an .htaccess file in the file uploads directory, with: SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006 (Advisory is at https://drupal.org/files/sa-2006-006/advisory.txt ) That also shows what a persistent problem this has been in the LAMP webserver stack for many years. I really hope FastCGI/FPM is an opportunity to put this right, among other things. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/503245be.8040...@pyro.eu.org
Re: Possible release note for systems running PHP through CGI.
On Aug 20, Wouter Verhelst w...@uter.be wrote: But some sites accept file uploads with arbitrary names, perhaps expected to be a JPEG image, but actually named bar.php.jpeg and containing malicious server-side PHP which they could execute from the browser. Don't Do That Then(TM). I see that you are not in the web hosting business. g Millions of web sites do this, so now matter how a bad practice this is (and I agree that it is) we need to do everything possible to work around insecure web sites. Also, we are talking about PHP: if educating developers were possible, they would not use PHP in the first place. The right solution to this problem is instead to write your upload scripts so that they True. But you do not dictate solutions to the 16 year old webmaster who happens to be the cousin of your customer. -- ciao, Marco signature.asc Description: Digital signature
Re: Possible release note for systems running PHP through CGI.
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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201208202012.47643...@debian.org
Re: Possible release note for systems running PHP through CGI.
On Mon, 2012-08-20 at 09:02 +0200, Wouter Verhelst wrote: 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? I think that's really wrong style then... Content generated by PHP files should have it's Content-Type header (and others) set from within PHP. The bug (which is a security problem) overweights the feature here, IMHO. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Possible release note for systems running PHP through CGI.
On Mon, 2012-08-20 at 14:06 +0100, Jon Dowland wrote: On Mon, Aug 20, 2012 at 12:58:42AM +0200, Christoph Anton Mitterer wrote: But if anyone would lobby that (release goal: default to CGI/FCGI), they'd have definitely my support :) A bit late for wheezy, do you mean for +1? Yeah,... of course not for wheezy ;-) Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Possible release note for systems running PHP through CGI.
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 mixmatch 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 Description: S/MIME cryptographic signature
Re: Possible release note for systems running PHP through CGI.
Charles Plessy ple...@debian.org (19/08/2012): This will interrupt upgrade of servers using php5-cgi, but to avoid surprises, the rough consensus in #674089 is also to document the same information in the release notes. 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. Mraw, KiBi. signature.asc Description: Digital signature
Re: Possible release note for systems running PHP through CGI.
On 12-08-19 at 11:17am, Charles Plessy wrote: - PHP scripts can be executed by Apache httpd through libapache2-mod-php5 or php5-cgi. Debian recommends libapache2-mod-php5, but there are still thousands of installations wich report the use of php5-cgi according to the Popularity Contest statistics. FWiW, out of the ~7'500 popcon hits of regular use of php5-cgi, ~900 also regularly uses suphp, so might be unaffected by this issue. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Possible release note for systems running PHP through CGI.
Charles Plessy ple...@debian.org writes: In summary: - PHP scripts can be executed by Apache httpd through libapache2-mod-php5 or php5-cgi. Debian recommends libapache2-mod-php5, but there are still thousands of installations wich report the use of php5-cgi according to the Popularity Contest statistics. Just to mention, one of the reasons to use php5-cgi instead of libapache2-mod-php5 is that one can achieve much better privilege separation (at the significant cost of speed) by using suexec or something akin to suexec and running scripts via CGI. That's what we do locally at Stanford for our general sandbox web service (as opposed to the more restricted ones that don't allow arbitrary user CGI scripts): we use a locally-modified suexec that also chroots and acquires file system credentials specific to the particular web site. That way, insecure PHP only permits a compromise of that particular web site and not any other hosted on the same servers. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehn2eq89@windlord.stanford.edu
Re: Possible release note for systems running PHP through CGI.
On 19/08/12 03:20, Charles Plessy wrote: - PHP scripts can be executed by Apache httpd through libapache2-mod-php5 or php5-cgi. Debian recommends libapache2-mod-php5, but there are still thousands of installations wich report the use of php5-cgi according to the Popularity Contest statistics. 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? Regards, Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/okj7g9-bb4@silverstone.rilynn.me.uk
Re: Possible release note for systems running PHP through CGI.
On Aug 19, Charles Plessy ple...@debian.org wrote: - PHP scripts can be executed by Apache httpd through libapache2-mod-php5 or php5-cgi. Debian recommends libapache2-mod-php5, but there are still This is another issue which concerns me, since mod_php forces the use of preforking apache, which means that the server will either stop serving pages or OOM at the first hint of real traffic. (And obviously mod_php is wildly insecure for multitenants servers.) thousands of installations wich report the use of php5-cgi according to the Popularity Contest statistics. Yes, because sensible people who need PHP will try to use it as CGI/FastCGI (or FPM, finally in wheezy). - This breaks the websites executing PHP scripts through php5-cgi, and a solution is being be documented in the php5 package's NEWS file. http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=commitdiff;h=f7a6351c620075a9d2a551fbed38ea26919f0d94 I think that this entry is too mild/vague: - including but possibly not limited to the Apache HTTPD Server: such a major issue justifies being specific about the affected packages - too many mays, while the entry should clearly state, maybe in caps, something like this will almost certainly break your server if you use PHP as CGI/FastCGI, and also leak your source code and passwords This will interrupt upgrade of servers using php5-cgi, but to avoid surprises, the rough consensus in #674089 is also to document the same information in the release notes. I agree with the interrupting upgrades for such a major package is going to be annoying. 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/ ? -- ciao, Marco signature.asc Description: Digital signature
Re: Possible release note for systems running PHP through CGI.
On Sun, 2012-08-19 at 12:43 +0200, Cyril Brulebois wrote: 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 don't quite understand how we could willingly let run our users into broken sites and even worse possible security issues. Be it low-popcon or high... and by the way I have some problem that popcon is nowadays used as justification for many things... after all... it's not representative, is it? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Possible release note for systems running PHP through CGI.
On Sun, 2012-08-19 at 17:26 +0200, Jonas Smedegaard wrote: FWiW, out of the ~7'500 popcon hits of regular use of php5-cgi, ~900 also regularly uses suphp, so might be unaffected by this issue. mights are not something we should build our security upon. And apart from that... I had a very short glance at suphp,... and it seems it also uses mime-types for handlers, right? So that means setups may likely also be vulnerable to the removal of the types from mime-types. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Possible release note for systems running PHP through CGI.
On Sun, 2012-08-19 at 18:16 +0100, Roger Lynn wrote: How does this affect other web servers? There was someone mentioning that lighthtttp may use /etc/mime.types, too. So yes, basically anything (though I guess security critical things should only be found at webservers, as they typically serve interpreted PHP) using /etc/mime.types in such a manner may be vulnerable. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Possible release note for systems running PHP through CGI.
Hey Russ, Marco. On Sun, 2012-08-19 at 22:32 +0200, Marco d'Itri wrote: thousands of installations wich report the use of php5-cgi according to the Popularity Contest statistics. Yes, because sensible people who need PHP will try to use it as CGI/FastCGI (or FPM, finally in wheezy). Well... unfortunately upstream is quite stupid (to be honest) in that they suggest mod_php as default. It's from a security point of view the worst possible solution and from a performance view at least not better than FPM (likely worse). I would like to see Debian deviate from this and actively suggest CGI or FCGI... but all my notes towards this were immediately turned down and I did not even succeed in convincing them in adding far less intrusive security and/or performance optimisations (just have a look at #674205) But if anyone would lobby that (release goal: default to CGI/FCGI), they'd have definitely my support :) I think that this entry is too mild/vague: - including but possibly not limited to the Apache HTTPD Server: such a major issue justifies being specific about the affected packages The reason why I wrote it that vague is, that you cannot definitely tell whether a package is vulnerable or not, because it's not the package but the configuration. So if one made his own Apache config, used RemoveType php as I suggested in the respective bugs and set the types new, one would be perfectly safe. And further,... at least I was not able to make a definite list even of possibly affected packages. Apache with PHP-CGI/FCGI is affected for sure... mod_php not, but only because Ondrej included a sane default config for this. 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/ ? That was just the idea I had yesterday night, but I haven't had time yet to file a bug for it. But actually I'd suggest that this goes to php5-common, and ALL PHP SAPIs share a single conf. Nevertheless,... this solves the issue ONLY for apache,... and won't save use (at least if we don't ignore the security of our users) from adding notes in NEWS file and release notes. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Possible release note for systems running PHP through CGI.
On Sun, 2012-08-19 at 22:32 +0200, Marco d'Itri wrote: 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/ ? Again, I don't think this saves us from the current need for a NEWS file and release notes entry, but... I've opened #685340, proposing: a) a single php config file for Apache, that enables the MIME-Types (or handlers) b) but that does _not_ enable (Action and ScriptAlias directives) PHP globally on the server. I think this is unclean and not the best with regards to security. Also not any possible vhost needs the mapping to /cgi-bin/. The goal should be that sysadmins (or package maintainers) set the Action and ScriptAlias directives in their config snippets... But this is definitely something for jessie. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Possible release note for systems running PHP through CGI.
On Sun, 19 Aug 2012, Marco d'Itri wrote: On Aug 19, Charles Plessy ple...@debian.org wrote: - PHP scripts can be executed by Apache httpd through libapache2-mod-php5 or php5-cgi. Debian recommends libapache2-mod-php5, but there are still This is another issue which concerns me, since mod_php forces the use of preforking apache, which means that the server will either stop serving pages or OOM at the first hint of real traffic. (And obviously mod_php is wildly insecure for multitenants servers.) You need php-cgi with something like fcgid to have it properly isolate several web applications and still be somewhat scalable. mod-php is just a toy in its current state, good enough to run stuff at home as long as it is restricted to localhost... thousands of installations wich report the use of php5-cgi according to the Popularity Contest statistics. Yes, because sensible people who need PHP will try to use it as CGI/FastCGI (or FPM, finally in wheezy). Indeed. 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/ ? That, and leave mime.types alone. If the problem is caused by mod-php under apache, any simple solution should be biased towards breaking mod-php under apache, not everything else. A good solution would not break anything. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120820004115.gc8...@khazad-dum.debian.net
Possible release note for systems running PHP through CGI.
Dear release team and developer community, due to changes in the mime-support package, upgrade of systems serving PHP websites through CGI will not be automatic. There is http://bugs.debian.org/674089 (critical) where the issue is discussed, and I would like to reassign it to the release notes. Please let me know your thoughts about this. In summary: - PHP scripts can be executed by Apache httpd through libapache2-mod-php5 or php5-cgi. Debian recommends libapache2-mod-php5, but there are still thousands of installations wich report the use of php5-cgi according to the Popularity Contest statistics. - 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. - 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 is being be documented in the php5 package's NEWS file. http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=commitdiff;h=f7a6351c620075a9d2a551fbed38ea26919f0d94 This will interrupt upgrade of servers using php5-cgi, but to avoid surprises, the rough consensus in #674089 is also to document the same information in the release notes. Therefore, I am probably going to reassign #674089 to the release-notes pseudo package, unless a consensus emerges that this is not the proper solution. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120819021726.gc20...@falafel.plessy.net
