Hi, 2012/4/10 Stas Malyshev <smalys...@sugarcrm.com>: > Hi! > >> Tom's FRC is trying to introduce tag less PHP script. >> However, it does not fix well known PHP vulnerability. i.e. LFI/RFI >> IMHO, this change introduce more complexity and do not solve >> any problem. > > I'm not sure I follow - which PHP vulnerability you are talking about?
Not many people read RFC, so I should have written example attack scenario. Because PHP is embedded scripting language, PHP code may be embedded anywhere/any files. One convenient place is session storage. i.e. file save handler. ==Exploiting LFI without file uploads== 1. Find FLI vulnerable application. 2. Find a way to inject $_SESSION 3. Use session file to execute arbitrary PHP code. Files save handler is the default, attacker knew his/her session ID and can guess session.save_path easily. Therefore, there are high possibility that attacker could take control of web server via LFI. == Possible protections == It's possible to prevent session FLI by adding "<?php die()?>" to top of session data. It's not clean solution and has compatibility issue with other systems. (e.g. There are PERL/Ruby/Python scripts that decodes PHP session data) It's also possible that makes save_path unpredictable. It won't worth to do that. IMO. If developers/administrators could make PHP tag non mandatory, almost all LFI could be protected by simple file validation. i.e. Check the first line if it begins with "<?php" == Validation Issues == Invalidating PHP script contained file is not simple. Attacker can inject PHP code into any file and anywhere. 1. "<?", "<%" may occur in binary 2. <script language= is common in HTML Forcing programmers to check binary/HTML/mail messages/etc would be impossible. == Solution == Please take a look at the RFC. https://wiki.php.net/rfc/nophptags Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
