Re: Run-time taint support proposal

On Sat, 2006-12-16 at 07:31 +0000, Lester Caine wrote: > Wietse Venema wrote: > > Ilia Alshanetsky: > >> And here is your first exploit, let's say we say > >> mysql_real_escape_string() takes tainted data and makes it untainted, > >> what happens when this "safe" data is passed to exec(). > > > > You need a malicous code writer to have an exploit. As far as I > > know, PHP is not a platform for secuerly executing hostile code. > > > >> You are going > >> to need to deal with different levels of taint-untainted and 1 bit is > >> not going to give you that flexibility. You are going to need an int/ > >> long, maybe even a long long. > > > > Sandboxing malicious code requires a lot more than taint levels. > > > > I'll be happy to provide that, but it's outside of the contribution > > that I'm trying to make for 2007. Right now I am merely targeting > > the non-malicious programmers. > > In that case do we really need something clogging up the code base? > Improving the performance of tools like PHPEclipse would seem to me to > be a better use of resources than adding the same sort of checks into > the runtime engine? Ummm, something like taint checking would be available regardless of your favourite code editor (mine is joe). I don't see what PHPEclipse or any specific editor has to do with the evolution of PHP. Cheers, Rob. -- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------'