Hi Rowan,
On Sat, Feb 15, 2014 at 2:10 AM, Rowan Collins <[email protected]>wrote:
>
>
>> But if somebody is using include() for non-PHP data, they're using
>> the wrong function anyway, end of story.
>>
>>
>> Right. This is what I would like to change.
>> In other languages, such script inclusion ends up syntax error, end of
>> attack.
>>
>
> I was talking here about my cases 3 and 4, where the author is
> *deliberately* using include for something other than code. There is
> already a correct function for that, which is readfile(), or more likely
> file_get_contents() and then some processing, so no changes are needed to
> introduce it.
>
>
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
These are abuse of feature. It's better to disable such usage.
>
>
> There are number of ways to inject piece of PHP code into files. Attacker
>> can exploit other feature/vulnerability to take over server completely.
>> Session file is one of the common method.
>>
>
> Are session files relevant to this discussion, or was this just a side
> note?
Yes, it is relevant as PHP executes fragment of code in a file always. Many
codes save user supplied data in session. i.e. It can be used for LFI
attack that executes arbitrarily codes .
> Compile error will not display any code/contents except a piece displayed
>> as error message.
>>
>
> That's not quite true. A fatal error can occur after output has been
> flushed through to the browser. The include statement will succeed (acting
> like readfile()), and the fatal error, if any, will happen afterwards, e.g.
> because an expected class definition was not loaded.
When a language executes data files as program, it ends up with syntax
error during compile time almost always. PHP compiles script, then
executes. Program may output something before data file inclusion, but it
must be intended output. Data file inclusion results in syntax error and
content would not be exposed.
Attacker may disguise script a data file. Insufficient data file validation
may permit script execution in other languages, too. I'm not concerned much
about this case. New RFC will address this issue, though.
> Take a look at vulnerability reports, you'll find number of LFI that
>> could be prevented by this RFC.
>>
>
> I looked at some of the examples in the RFC, but I don't understand how
> they relate to this proposal. No amount of links to vulnerability reports
> can tell me that, but you can.
>
> What I am asking for is an example - real or artificial, I don't mind -
> with an explanation of how it behaves now, and how that behaviour would be
> improved by the proposed change.
>
> Note that I'm not trying to shoot down your proposal - on the contrary,
> I'm trying to make sure its benefits are clearer, so that people will have
> a better means of judging it.
I'll abandon this RFC since I came up with better idea. New RFC will
address all issues have been discussed in this and other threads. All
discussions were valuable. Thanks a lot to all!
Regards,
--
Yasuo Ohgaki
[email protected]