Hi,
2012/4/10 Stas Malyshev <[email protected]>:
> 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
[email protected]