Russell Nelson wrote: > Nelson Menezes writes: > > The potential for inclusion of malicious code is, if > > anything, a common oversight, not a design flaw. > > If it's a common oversight, then it *is* a design flaw. > > > 1. Create an INI_ALL variable that means something like "allow fopen > > wrappers in include/require" and default it to whatever is thought > > appropriate -- if it *is* a very common oversight, maybe false. > > That would solve the problem. You could still use the sharp edges of > 'include', but you would have to take the sheath off first. > > Does anyone disagree with Nelson's suggestion? If I wrote the patch, > who should I submit it to? It ought to be pretty small, so I could > post it here, but that's probably not right.
Yes, most of us disagree. There will be a more complete set of input filtering tools available soon which addresses a broader range of input filtering problems like this one. Simply patching this one isn't going to help much as this particular one is not that common these days. Forget your Google searches and go look at actual vulnerability reports for the last 3 months. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
