Martin Schulze wrote: > Hey! > > What do people on this list think about fixing PHP include files in a > DSA that are accessible via HTTP as well and contain one bug or > another as they are not supposed to be accessible via HTTP but > accidently are.
Patching them like Squirrelmail has fixed this may be a better solution before everything is in place. > I'm rather annoyed by the lack of comptence of some PHP coders who > manage their project in a way so that include files are stored within > the regular DocumentRoot and are hencely accessible via HTTP as well. > Include files normally also don't contain any precaution about being > "executed" standalone. I both agree and disagree with you. The reason I disagree with you, is that this works fine for php scripts that come with debian, but thats it. Everything a normal user installs is still a problem and even a bigger problem then the packages from debian. Also I counted 95 packages depending on php4 in Sarge at the moment versus way to many entries when you query freshmeat? > These files should not be accessible via HTTP in the first place but > put into /usr/share/something instead and included from there. Is this going to solve the problems? Don't get me wrong, because I love your goal but I don't believe that what you suggesting right now is going to solve the problems with PHP at this moment. Maybe its an idea to get in contact with Rasmus about securing PHP, because he's trying to get a more secure and sane php4.ini in the upstream releases. Unluckily his attempts fail, also because distro builders don't support his action. It seems not many are interessent in selling a webserver distro that can't run all the ****ware like phpbb, php(my|pg)admin, phpnuke, the list is long, out of the box. Personally I don't want a php-script running a variable as of it was part of its own code or including code from other untrusted sites. Beside the fact that your plan has some issues with multiple installations because some application require that for multiple vhosts. It may be a better idea to start with PHP itself and ask during installation of the users wants to install a secure or insecure version of php4.ini. The same is done with setuid issues for example. > As examples see the following problems: > > CAN-2005-0459 - information disclosure in phpmyadmin This one goes even further then information disclosure and isn't the reason you want it out of your docroot at this moment. Using unchecked variables isn't wise at all time. > CAN-2005-0870 - cross site scripting in phpsysinfo Another example of what Rasmus is fighting for the last couple of years. Make the default php4.ini more sane and secure. But the bottomline for both issues, don't display error messages on screen, but in a logfile. And also both issues are straight examples out of the textbooks, where xss can be disabled almost everytime with changing php4.ini. Sorry, if this doesn't sound happy, but I'm at the point where I start to hate PHP, PHP-applications and sysadmins who don't want to tell a developer/user that his/here application doesn't run because it wants to do dangerous things. But I'm pleased that these issues are now being addresses by at least one distro in public. Hans -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
