Yasuo Ohgaki wrote (on 11/02/2014):
Local script inclusion is*much grater security threat* than local script
expose.
I've been trying to follow the pros and cons of this RFC, and I'm really scratching my head on what the security benefit is supposed to be.
As I understand it, for this to even be relevant security-wise, it would need to involve a dynamic file path being included, and an attacker somehow influencing either which file was loaded, or the contents of that file.
The scenarios I can see are:
1) the include was intended to be PHP code, and the attacker substitutes different PHP code of their choice
2) the include was intended to be PHP code, and the attacker accesses non-PHP data already on server
3) the include was intended to be non-PHP data, and the attacker substitutes PHP code of their choice
4) the include was intended to be non-PHP data, and the attacker accesses different non-PHP data already on server
This sentence in the RFC Summary sounds like it's talking about 3:
However, embedded scripts are serious security risk as it can executes any PHP code in any files.
But if somebody is using include() for non-PHP data, they're using the wrong function anyway, end of story.
Barring bugs in the engine (e.g. null byte handling) 1 and 4 are something that no language can guard against: substituting code for code, or data for data (if include() couldn't do it, file_get_contents() could). There's a lot of talk in the RFC about validating file *contents*, but it seems to me that careful whitelisting of file location and naming is generally more relevant (e.g. "/etc/passwd" doesn't end in ".php", so it's kind of obvious you shouldn't be passing it to an include statement).
2 seems to be more relevant to me: without the "always echo if no <?php found" rule, it's easier to trick include() into acting like readfile(). The failure to load the expected PHP code would probably cause a Fatal Error anyway, but the contents might be exposed first.
But that doesn't seem to be the exploit that is being discussed on this RFC. Or am I misunderstanding completely?
Could somebody enlighten me with an artificially simplified example of a code execution attack that is possible today but would be prevented (or preventable) with the proposed change?
Thanks,
--
Rowan Collins
[IMSoP]