On Thu Jun 05, 2003 at 07:49:58PM -0400, Dan Scott wrote: > > I'm almost tempted to say we should have this by default. Two things come > > to mind here (which is why I'm not in a super hurry to fix this thing, and > > likey will issue an advisory with info on how to correct the problem rather > > than a new php-ini package): > > > > - anyone using phpinfo() and making it publically accessible is insane > > because it offers more than just XSS problems; the data exposure alone is > > likely more damaging than any XSS vulns > > - I dislike putting out updates for config fixes; give me a patch for php > > itself and you've got yourself an update (although I would hesitate on > > something as trivial as this) > > - XSS vulns are so widely in existance and, really, pretty petty in the > > grand scheme of things that they don't really warrant an update (in my > > mind) > > > > Ok, three things. =) > > > > That being said, I'd be more than happy to see this as part of the default > > php in cooker and Mandrake from this point forward. Obviously, a user can > > change it after the fact (or, if we decide to leave it, could change it to > > the above after the fact as well). > > > > Of course, people dislike it when I introduce or suggest better security
Like I said... > > measures, so I suspect the consensus from people will be to leave well > > enough alone. Although (tip for anyone doing any hosting), one should > > disable this function globally on a server if you allow others to host web > > pages on your machine. > > Security issue? Maybe. But only if we shipped a sample PHP script that > was accessible by default and which used that function. I never claimed this was a serious security issue. Did you read what I wrote above as to not issuing an update? If I thought it was a serious issue, an update would be in the works. > You could see that patch as being similar to removing strcpy() from > glibc; sure, it would arguably improve the security of any programs that > were updated to use strncpy(), but it would also dramatically increase > the number of patches required to make packages available on your > distro. Ummm... no doubt. You're preaching to the choir, thanks. > Yeah, okay, phpinfo() is far less useful than strcpy(), but remember to > take into account the number of PHP tutorials that use > > <?php echo phpinfo(); ?> > > as the equivalent of "Hello, world" and determine which case you want to > handle: > > * disabling phpinfo() and dealing with people complaining that PHP > doesn't work on Mandrake, because phpinfo() is a standard PHP function > documented at php.net and within numerous books, tutorials, articles > > * leaving phpinfo() enabled and dealing with the security threat posed > by a PHP developer who writes a script using phpinfo() and then makes > that script accessible on a public server Frankly, either would work for me. As I said before, it's really not that big of a deal either way. In one instance, you disable it, in another, you enable it. I honestly don't see what the fuss is. As far as an update goes, however, changing how PHP works all of a sudden is not the best way to go... I'd rather fix PHP itself than use a hack and impose it on everyone (informing individuals, on the other hand, is perfectly acceptable). Anyways, in my mind, having a script with phpinfo() publically available is stupid. I disable this on my own servers because I host other people's websites and have little control over thier content. And if they really needed that info, they could just ask. > I suspect the first case is much more likely to occur. Disabling part of > the published API for a language is a recipe for much wailing and > gnashing of teeth. Bah. It's a 10sec fix. In the grand scheme of things, no matter how it is dealt with (if at all), it's pretty minor. Anyways, I suspect a fix will be in place (in PHP itself) before 9.2 is out so there isn't that much of a big deal. I also think you should re-read what I wrote since I made it as a suggestion that I knew would return responses like this. And I only made it for cooker alone; doing it in release versions of PHP isn't an option. -- MandrakeSoft Security; http://www.mandrakesecure.net/ Online Security Resource Book; http://linsec.ca/ "lynx -source http://linsec.ca/vdanen.asc | gpg --import" {FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
pgp00000.pgp
Description: PGP signature
