On Thu, 2003-06-05 at 18:49, Vincent Danen wrote: > On Thu Jun 05, 2003 at 09:57:20PM +0200, Oden Eriksson wrote: > > > I found this the other day: > > > > http://archives.neohapsis.com/archives/bugtraq/2003-06/0027.html > > > > ..., and I thought I should share this info and a possible fix: > > > > --- php.ini 2003-01-06 05:40:15.000000000 +0100 > > +++ php.ini.oden 2003-06-05 21:58:02.000000000 +0200 > > @@ -191,7 +191,7 @@ > > ; This directive allows you to disable certain functions for security > > reasons. > > ; It receives a comma-delimited list of function names. This directive is > > ; *NOT* affected by whether Safe Mode is turned On or Off. > > -disable_functions = > > +disable_functions = phpinfo > > > > ; Colors for Syntax Highlighting mode. Anything that's acceptable in > > ; <font color="??????"> would work. > > 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 > 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. 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. 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 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. -- Dan Scott <[EMAIL PROTECTED]>
