On Tue, Mar 6, 2012 at 11:40 AM, Ferenc Kovacs <tyr...@gmail.com> wrote:
> > I don't like this, I mean one can end up printing out his sourcecode if > - those files are publically available through the document root This can also occur if the server is mis-configured. That said, one way to deal with this. One would be to allow the server itself to start PHP with the file being loaded as tagless. In either event though we're dealing with a config change, and users don't always remember to do those when they switch versions. Would current software break though? I don't think so. Anyone doing this would (should?) be aware of the ramifications. I'm personally not a fan of putting all the PHP files in the web document root, but I can understand why its done and I know its the current most common practice. > or > - if he somewhere used a wrong argument, and includes a tagless file with > the (default) with-tags option. > on the other hand, a html file page with php code examples (but without php > tags) could be turned into executing those examples if the tagless option is > used. That's actually up in the air as to how this is implemented. If implemented such that the parser just appends "<?php" to the start of the file inclusion (the laziest way to implement this feature) then any code block in there could possibly execute. To your first point this would mean the first block of code would be ignored and echoed out if it was mis-imported up until the parser finds a closing tag, and then finds a new opening tag. Then code would begin executing, and an attacker might pull off something with this. More likely though the code is going to parse error having come into the execution at an unexpected moment. If implemented such that 'tagless' truly means tagless and using php tags would result in a parse error in that mode the attack becomes much harder to pull off. So with your first point the if they import a tagless file with the wrong file everything gets echoed out as text because there would be no tags to pick up on unless the attacker is *very* sneaky and puts it in the quotes of an echo statement. As to the html, trying to import a html file with php code examples as a tagless file is going to fail, and fail hard, with the very first html tag or the doctype declaration of <!DOCTYPE html> I feel neither example is really a new vulnerability though. If anything, it makes code injection a bit trickier. But the basic mode of exploit isn't going to change. And the programmer working with this should be able to correct his mistake and move on. > > > I would support the namespace option though. Of the two this one is actually the one that scares the heck out me in terms of what can go wrong if it is misused. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
