Bug#687307: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
On Fri, 2012-10-26 at 13:18 +0200, Ondřej Surý wrote: + It is also advised that + you check your custom configuration whether it's not vulnerable to + foo.php.jpeg attacks. The php5_cgi configuration snippet can be used + as base - it's important to use FilesMatch or Files directive to + limit the handling to the last extension. Can we perhaps explain a bit more, what the foo.php.jpeg attack is? The last sentence hints it already a bit,... but I guess without clear explanation people may simply skip it. I think it became clear that we are stuck with no solution which would work for anyone Do you agree... that we should work on some hopefully general-everything-works framework for jessie? Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#687307: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
On Sat, Oct 6, 2012 at 9:51 PM, Stefan Fritsch s...@debian.org wrote: Hi Ondřej, I also cannot think of any configuration that would make everyone happy. At the moment, I fear this can only be solved by more documentation. Maybe one could add such a paragraph to the NEWS entry of php5-cgi 5.4.4-5, e.g. before The standard configuration now also... : WARNING: The new configuration may override other configuration directives you may have added locally for the .php extension, for example for FastCGI processing. This behavior is caused by FilesMatch configuration sections overriding directives appearing in global server or VirtualHost scope. You should review and test your configuration and verify that your php scripts work as expected. In the end I have used slightly different text with a warning to check the existing setup foo.php.jpeg vulnerability. Improvements welcome (as a patch, not as a rant). + The new (dummy) php5_cgi configuration uses SetHandler directive and + thus it might interfere with your existing custom configuration like + FastCGI (mod_fcgid or mod_fastcgi). In that case please disable + php5_cgi module (a2dismod php5_cgi) to reenable the existing + functionality of your custom configuration. It is also advised that + you check your custom configuration whether it's not vulnerable to + foo.php.jpeg attacks. The php5_cgi configuration snippet can be used + as base - it's important to use FilesMatch or Files directive to + limit the handling to the last extension. I think it became clear that we are stuck with no solution which would work for anyone, so this is the minimal variant of what we should do in PHP package. If somebody comes with better solution (or just tests the non-magic mime-types as written down by sf in http://wiki.debian.org/Apache/WheezyMimeTypes), I think we can still change that before release. But now we at least need more test in php5-cgi.NEWS. 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#687307: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
On Thursday 11 October 2012, Charles Plessy wrote: Le Mon, Oct 08, 2012 at 03:38:10PM +0200, Ondřej Surý a écrit : Just one last question which came to my mind. Would this all be fixed if we added non-magic type to mime-support (e.g. http://bugs.debian.org/670945) and reverting the changes done in the php5-cgi package? That I think would justify change in the mime-support package. Too much breakage on every front now. And remove the php-cgi.conf completely, right? So this would introduce a different fix for the multi-views problem. Are you sure that there is no other problem that we would re-introduce? Maybe it's worth a try. Hello Ondřej, Stefan, and everybody, Do you think that there is a way to fix #589384 (the *.php.foo problem) without removing the application/x-httpd-* media types ? There is at least no solution that is obviously right. I fear that regardless what we do, we will break some configs. Besides removing the media types from /etc/mime.types, one could add a RemoveType php ... to the apache config (but where?). Or maybe, one could also set AddHandler default-handler php The latter is an idea I just had, I have not thought it through or tested it. I did not realise before that in the current release cycle, Apache stays at version 2.2 and that in Jessie, configurations will need to be re-adjusted anyway. I think that it is a good argument for a compromise, provided that #589384 stays solved and that we agree that in Jessie the media types application/x-httpd-* will be removed from /etc/mime.types. Of course, it is even better if there is an easy way to adjust the priority of the SetHandler statement of php5_cgi.conf in a way that does not break FastCGI configurations. I think there are rather too many possibilities and the pros/cons of each one get lost in this thread. (Well, that is partially my fault because I take so long to respond, but I have been busy :-( ) Maybe it would be better to create a single document with all possible solutions and pro and cons? I have started to create such an overview at http://wiki.debian.org/Apache/WheezyMimeTypes but it is not finished yet. Feel free to add more infos/solutions/pros/cons. The page may come in handy for the Jessie, too. Christoph: For mod-fastcgi/mod-fcgid, the file.fcgi.foo problem is somewhat mitigated that they require Options ExecCGI, too. And AFAICS that is not set by default. Any opinions if this is good enough for wheezy? I lean towards yes, but maybe I am missing something. Besides, it would be interesting to check how mod_action behaves... 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#687307: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
Hey folks. On Tue, 2012-10-16 at 00:16 +0200, Stefan Fritsch wrote: And remove the php-cgi.conf completely, right? So this would introduce a different fix for the multi-views problem. Are you sure that there is no other problem that we would re-introduce? Maybe it's worth a try. There is at least no solution that is obviously right. I fear that regardless what we do, we will break some configs. I'd say we should sit together after wheezy however,... searching for some best-as-possible-overall-framework ;) Besides removing the media types from /etc/mime.types, one could add a RemoveType php ... to the apache config (but where?). I proposed that previously to Ondřej but only as a poor-man's guarantee... I wouldn't want to see that we really rely on it,... cause it may easily break... One never knows what upstream changes... e.g. at some day there might be a change in the order of evaluation from RemoveType and TypesConfig... or evil things like that... Or maybe, one could also set AddHandler default-handler php The latter is an idea I just had, I have not thought it through or tested it. Sounds like it could work,... and actually a nice idea ;) ... but it seems somewhat ugly to me... you know adding handlers and assigning stuff just for hackings something into... We cannot know how much something like this breaks... just imagine if a user has already his own default-handler defined. Maybe it would be better to create a single document with all possible solutions and pro and cons? I have started to create such an overview at http://wiki.debian.org/Apache/WheezyMimeTypes but it is not finished yet. Feel free to add more infos/solutions/pros/cons. The page may come in handy for the Jessie, too. Good idea... I hope I'll find some time into looking at it... But in general... I'm a bit scared that we clash into the release of wheezy with neither a perfect nor an at-least-somewhat-secure solution. So question the the group is: Should we continue with investigating in a perfect solution (and that wiki seems to somewhat go into that direction)... or should we simply admit there's a shitty situation for wheezy... add the necessary release notes with big fat exclamation marks... and shame ourselves till we come up with the uber-solution in jessie? ;-) Christoph: For mod-fastcgi/mod-fcgid, the file.fcgi.foo problem is somewhat mitigated that they require Options ExecCGI, too. And AFAICS that is not set by default. Any opinions if this is good enough for wheezy? I lean towards yes, but maybe I am missing something. Well... phew... I mean don't get me wrong... nearly all what we do here is about teaching users and/or helping them not to shoot themselves... so in theory you're right and this is enough... on the other hand: Practise looks like this that users often have merely an idea what they do... and I'd feel better, if both mods also place some Files block around. Actually,... I'd even feel better if they stop automatically enabling things. And this is not my usual security-paranoid installed-packages-shouldn't-enable-their-stuff-automatically talking... it's rather that in this special cases (namely Apache)... they enable things globally for the whole server... which is (to my experience) rarely needed. We could help users from potential security troubles,... if we force them to decide in which context they want to enable things. But how to proceed now? In general, if we secure these two mods from the evil.fcgi.jpeg issue, we have the same problem as with PHP (there Ondřej added a according entry to NEWS and README.Debian) namely that we potentially break some setups (those from such devilish admins coming straight from hell and used http content negotiation in some way with their interpreted stuff. I personally think it's definitely worth! Then we have the options: a) Either just secure it with Files blocks around the diretives that add the handlers... b) or disable global per-default activation but still document in each of the two packages how to do it right. I'd vote for (b). Depending on what you guys from the Apache Maintainer group say... I'd open respective bugs, and help Tatsuik and Taku with documentation and stuff... Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#687307: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
Hi Charles. On Thu, 2012-10-11 at 09:06 +0900, Charles Plessy wrote: Do you think that there is a way to fix #589384 (the *.php.foo problem) without removing the application/x-httpd-* media types ? I would say no, well at least not if we also want to use these media types later on in Apache to select something for interpretation. The problem with using /etc/mime.types via the TypesConfig directive in Apache is the usual with Apache: Most mod_mime directives (and maybe also others) will assign a media type if just any extension (i.e. also the foo in file.foo.bar) matches. The usual way around this is to place these directives in e.g. Files ?*.bar /Files or FilesMatch ^.+\.bar$ /FilesMatch TypesConfig however is a server wide scope directive, so this won't work here. As I mentioned previously, I think it's very dangerous to use TypesConfig per default. It's evil by design and people should need to intentionally enable it (and then hopefully know what they're doing). I really think we should not fiddle around with mime-types anymore, or better: I think we should stop using it to enable files for interpretation, even if that may break now some setups. Of course we should provide release notes hints on how to make them work again, which is usually quite easy. Also, please consider that people using advanced stuff like FastCGI can be expected to know what they're doing. I did not realise before that in the current release cycle, Apache stays at version 2.2 and that in Jessie, configurations will need to be re-adjusted anyway. It would of course be nice, if we could postpone this to jessie, but... I think that it is a good argument for a compromise, provided that #589384 stays solved and that we agree that in Jessie the media types application/x-httpd-* will be removed from /etc/mime.types. Right now I see no way to prevent the evil.php.jpeg issue otherwise. And note especially, that also FastCGI is in principle vulnerable to this. Though I haven't checked right now, how they actually select the PHP files for interpretation (which may or may not prevent the issue). easy way to adjust the priority of the SetHandler statement of php5_cgi.conf I think it's determined by the loading order... which makes it basically impossible IMHO to really make sure it gets loaded as we want it to. in a way that does not break FastCGI configurations. Even then we need to check whether fastcgi or fcgid are vulnerable to the evil.php.jpeg isseu. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#687307: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
Oh and one more thing (even though this is PHP unrelated): Maybe I misunderstand something but it seems both: libapache2-mod-fcgid, which uses: IfModule mod_fcgid.c AddHandlerfcgid-script .fcgi FcgidConnectTimeout 20 /IfModule and libapache2-mod-fastcgi, which uses: IfModule mod_fastcgi.c AddHandler fastcgi-script .fcgi #FastCgiWrapper /usr/lib/apache2/suexec FastCgiIpcDir /var/lib/apache2/fastcgi /IfModule are highly vulnerable to the evil.fcgi.jpeg issue... Can you confirm this? Cause then we need to open some critical bugs. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#687307: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
On Sat, Oct 6, 2012 at 9:51 PM, Stefan Fritsch s...@debian.org wrote: This sucks. In hindsight, maybe the mime.types change should have been deferred until we ugrade to apache 2.4 and people have to adjust their configs anyway. But I think it's too late now to go back. And leaving the *.php.foo problem there for yet another release cycle would not have been a good solution either. Le Mon, Oct 08, 2012 at 03:38:10PM +0200, Ondřej Surý a écrit : Just one last question which came to my mind. Would this all be fixed if we added non-magic type to mime-support (e.g. http://bugs.debian.org/670945) and reverting the changes done in the php5-cgi package? That I think would justify change in the mime-support package. Too much breakage on every front now. Hello Ondřej, Stefan, and everybody, Do you think that there is a way to fix #589384 (the *.php.foo problem) without removing the application/x-httpd-* media types ? I did not realise before that in the current release cycle, Apache stays at version 2.2 and that in Jessie, configurations will need to be re-adjusted anyway. I think that it is a good argument for a compromise, provided that #589384 stays solved and that we agree that in Jessie the media types application/x-httpd-* will be removed from /etc/mime.types. Of course, it is even better if there is an easy way to adjust the priority of the SetHandler statement of php5_cgi.conf in a way that does not break FastCGI configurations. What do you think ? 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#687307: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
Stephan, thanks for the input. Just one last question which came to my mind. Would this all be fixed if we added non-magic type to mime-support (e.g. http://bugs.debian.org/670945) and reverting the changes done in the php5-cgi package? That I think would justify change in the mime-support package. Too much breakage on every front now. O. On Sat, Oct 6, 2012 at 9:51 PM, Stefan Fritsch s...@debian.org wrote: Hi Ondřej, I also cannot think of any configuration that would make everyone happy. At the moment, I fear this can only be solved by more documentation. Maybe one could add such a paragraph to the NEWS entry of php5-cgi 5.4.4-5, e.g. before The standard configuration now also... : WARNING: The new configuration may override other configuration directives you may have added locally for the .php extension, for example for FastCGI processing. This behavior is caused by FilesMatch configuration sections overriding directives appearing in global server or VirtualHost scope. You should review and test your configuration and verify that your php scripts work as expected. The README.Debian or the wiki page you are already pointing to should then list likely candidates for problematic local configurations, like AddHandler fcgid-script .php. Maybe it could also say, that if all else fails and the user is willing to live with the *.php.foo problem, the old behavior can be restored by replacing etc/apache2/mods-available/php5_cgi.conf with something like AddType application/x-httpd-php phtml pht php php3 php4 php5 AddType application/x-httpd-php-source phps to get the old behavior back. What do you think? This sucks. In hindsight, maybe the mime.types change should have been deferred until we ugrade to apache 2.4 and people have to adjust their configs anyway. But I think it's too late now to go back. And leaving the *.php.foo problem there for yet another release cycle would not have been a good solution either. Cheers, Stefan -- 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#687307: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
Hi, Ondřej Surý: Just one last question which came to my mind. Would this all be fixed if we added non-magic type to mime-support (e.g. http://bugs.debian.org/670945) and reverting the changes done in the php5-cgi package? IMHO that would be a good idea. (Subject to testing …) -- -- Matthias Urlichs signature.asc Description: Digital signature
Bug#687307: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
On Mon, 2012-10-08 at 15:38 +0200, Ondřej Surý wrote: Just one last question which came to my mind. Would this all be fixed if we added non-magic type to mime-support (e.g. http://bugs.debian.org/670945) and reverting the changes done in the php5-cgi package? I'm a bit unsure how/why that would fix the general problem? Perhaps you can elaborate a bit more on what your ideas are :) I haven't looked into absolute details but I think the main problem here is, that different SAPIs use different fixed handler-names. And even if all would use the same,... we'd have a problem, namely how to select the right one. That I think would justify change in the mime-support package. Too much breakage on every front now. Well... I think it's quite dangerous to again play around at mime-support. I mean we all know the problems arising from there,... not only the security issues like foo.php.jpeg, but also that we are again quite dependant on some other package. Admittedly, we're in quite a shitty situation now, so close to wheezy, but I somewhat agree to Stefan, in better just adding some more release notes. The next step would/could be to think about post-wheezy release goals for the overall PHP framwork in Debian. Which includes IMHO: - unifying as much (apache) configs as possible for the different SAPIs - other packages (i.e. packaged PHP programs) should not rely on PHP being activated by the php packages (especially not globally), but should rather give the user a debconf option on where (which webserver) to activated it how (always only local scope,... and questioning which SAPI) - make the different SAPIs co-exist more out-of-the-box...which i.e. also addresses this very bug The ideal state would be that one can enable all SAPIs in one Apache instance and even use them in the same vhost... differentiating per Directory (well at least as far as this is possible for all the SAPIs). Maybe this requires that we patch things like mod_f(ast)cgid ... to use other handler names. I have not yet an idea how all this could be achieved. But back to this very bug: If we say we solve this for now, by just adding release notes as Stefan proposed... then there is still one important thing left. Namely those I asked in the mails from: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687418#59 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687418#69 May we run into the problem, that again, files are accidentally served (as files)? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#687307: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
On Mon, Oct 8, 2012 at 9:51 PM, Christoph Anton Mitterer
cales...@scientia.net wrote:
On Mon, 2012-10-08 at 15:38 +0200, Ondřej Surý wrote:
Just one last question which came to my mind. Would this all be fixed
if we added non-magic type to mime-support (e.g.
http://bugs.debian.org/670945) and reverting the changes done in the
php5-cgi package?
I'm a bit unsure how/why that would fix the general problem?
Perhaps you can elaborate a bit more on what your ideas are :)
Basically it would bring the old behaviour back while not mangling
with custom Set/AddHandler directives in the apache. Remember the
php5_cgi.{load,conf} hack was introduced after decision to fix this
only in Apache - which in turn caused more breakage in custom setups
then expected.
Stefan, what do you think?
[...snip some unrelated future ideas...]
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#687307: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
On Mon, 2012-10-08 at 22:42 +0200, Ondřej Surý wrote:
Basically it would bring the old behaviour back while not mangling
with custom Set/AddHandler directives in the apache. Remember the
php5_cgi.{load,conf} hack was introduced after decision to fix this
only in Apache - which in turn caused more breakage in custom setups
then expected.
Ah... so you mean adding e.g. application/x-php (or whatever) but don't
use this with mod_php or normal CGI (where we'd still keep the
php5_cgi.{load,conf} then?)
Not sure about that...
I mean these types were removed for good reasons... and especially in
Apache people should at best stop using /etc/mime.types at all.
I somehow fear a bit,... that we might just end up with other new
(security?) issues being added.
Putting parts of PHP configuration (well I know it's not really that)
in other packages seems problematic to me IMHO the cleanest solution
would be, if PHP-packages add the necessary basic configuration to
installed webservers (ideally not only to Apache)... without activating
PHP.
The later then being done manually by the admin, or (more or less)
automagically by other packages.
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
Bug#687307: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
Hi Ondřej, I also cannot think of any configuration that would make everyone happy. At the moment, I fear this can only be solved by more documentation. Maybe one could add such a paragraph to the NEWS entry of php5-cgi 5.4.4-5, e.g. before The standard configuration now also... : WARNING: The new configuration may override other configuration directives you may have added locally for the .php extension, for example for FastCGI processing. This behavior is caused by FilesMatch configuration sections overriding directives appearing in global server or VirtualHost scope. You should review and test your configuration and verify that your php scripts work as expected. The README.Debian or the wiki page you are already pointing to should then list likely candidates for problematic local configurations, like AddHandler fcgid-script .php. Maybe it could also say, that if all else fails and the user is willing to live with the *.php.foo problem, the old behavior can be restored by replacing etc/apache2/mods-available/php5_cgi.conf with something like AddType application/x-httpd-php phtml pht php php3 php4 php5 AddType application/x-httpd-php-source phps to get the old behavior back. What do you think? This sucks. In hindsight, maybe the mime.types change should have been deferred until we ugrade to apache 2.4 and people have to adjust their configs anyway. But I think it's too late now to go back. And leaving the *.php.foo problem there for yet another release cycle would not have been a good solution either. Cheers, Stefan
