Stanislav Malyshev schrieb: >> Well yes. I think to solve this "once and for all" a public statement by >> the PHP group would be nice that says: > > I don't think they are "not important", just that they are not > important enough to want them fixed no matter the cost. Running shared > hosted server in a mode that relies on restricted code IMO is wrong > anyway, and for non-shared environment these problems could be > exploited only if specifically enabled by very badly written code. So > when there's a trade-off between having the language work better for > 100% of cases or protect those who run broken code on their servers - > the choice would be to make language run better. Again, that doesn't > mean bugs shouldn't be fixed - just the fix shouldn't make the > situation worse. Unfortunately we live in the real world, where people usually break into servers that run bad PHP code. And the more tight you make the OS, like CGI, separate user account, no write access to document root, chrooted document root,... The more obvious it becomes that local vulnerabilities matter. Because in such a environment you CANNOT break out of it with plain PHP code. You need to execute arbitrary machine code.
Remote PHP Code Execution Vulnerabilities will not be dead when allow_url_include is installed and disabled everywhere. Just keep in mind that the most popular PHP worm ever (Santy) that exploited phpBB was attacking through the /e modifier of preg_replace(). Really Bad Code exists everywhere and admins have a very bad feeling in their stomach when they have to install PHP applications. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
