On Fri, December 15, 2006 5:32 pm, Ilia Alshanetsky wrote: > > On 15-Dec-06, at 6:21 PM, Andi Gutmans wrote: > >> Well you wouldn't have to use tainted mode of course. This can/ >> should be >> turned off by default. > > safe_mode is/was off by default to, and yet a good chunk of hosts > enabled it under the assumption it would make their setups secure.
Well, duh, we labeled it "safe mode" It didn't make their server any slower. And it's "safe" So it must be good, right? :-) :-) :-) Perhaps the biggest "win" for "taint" not being another "safe mode" is that it's correctly labeled in the first place, unlike "safe mode" :-) >> I think having such a mode would be of great help to many users >> though. It >> would allow them to find any quirks in their data/input filtering >> and help >> them focus on where they should do a better job. > > I think people generally follow the path of least resistance and for > compat purposes I suspect most application will simply create a quick > wrapper to **untaint** all input data so they can use it within their > application without worrying about tainting getting in the way. Sure, some will. Just as some folks are now using extract on $_REQUEST to work around register_globals being off. >> Of course no one such >> solution will solve application-level security issues but it could >> end up >> being a very useful tool which helps people address the majority of >> such >> problems. > > Tainting may have helped if you are using straight forward data, but > what happens when you start doing appending or passing data through > string modification operations. I almost guarantee that there will be > a series of operations or function calls that if executed in a > certain order will mask tainted input making it appear safe. I'd > gladly provide you with examples, but there is no sample code, if I > have time I'll take a peak at Perl and Ruby that implement tainting > and see if a quick taint bypass can be devised. I'll save you the trouble. A simple preg that does NOTHING at all will mark the data as "untainted" in Perl. "taint" is not a magic bullet. It's just a big yellow triangle "WARNING" sign for a new developer, and a handy tool for the experienced to run through one of many safety checks in their development/review process. >> I've been on the fence here from the beginning. I am pretty sure >> this would >> be a very useful feature but I'm somewhat paranoid after the whole >> safe_mode >> saga. Stas pointing out the difference between safe_mode which is >> "trust >> everyone unless explicitly pointed out" vs. a possible approach >> here of >> "trust noone unless explicitly pointed out" might make the >> difference >> though. > > All it means that this breaks every applications and the security > benefits are somewhat ambiguous, but in all fairness the full > consequences are hard to predict without sample code. It breaks nothing unless somebody somewhere makes the decision that turning "taint" on is worth the support calls/questions they will get from developers who have no [bleep]ing clue what they are doing. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
