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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature