Re: Resolution for ver_export()/addslashes() encoding based script execution attack?
On Tue, 2014-02-25 at 13:01 +0200, Stas Malyshev wrote:
> Hi!
>
> > Engine supports SJIS/other encoding script execution. Therefore,
>
> I'm not sure what you mean by "other encoding script execution". Engine
> execution is the same regardless of the data you use, nowhere in the
> opcodes there's any encoding that is important.
I think Yasuo refers to
php -d zend.script_encoding=SJIS
> > addslashes()/var_export() behavior is security vulnerability just like
> > encoding based SQL/JavaScript injections.
>
> I don't see how it is "therefore". If there's SQL injection or JS
> injection that is not the result of wrong code, then let's outline them
> and consider them. Specifically for var_export, which behavior is
> broken? I see no mention of the specific examples in the RFC.
i think Yasuo assumes that results from those operations with a
script_encoding setting would be handled "correctly".
I don't think we can do that, though. zend.script_encoding is a hardly
documented feature which should be used with care.
The documentation of addslashes() refers to "characters". I don't think
the behavior should depend on PHP settings but like all "basic"
functions assume on ASCII compatible single byte strings. Adding magic
there makes it more confusing and harder to use. As said in a previous
discussion on this topic rather than using addslashes users should use
context-aware escaping functions. Using addslashes is almost always a
bad idea.
The situation around var_export() is a bit more complicated.
var_export() is used to create application configuration, cache data
etc. so one might expect the PHP which created that to be able to read
that, again. Doing this isn't easy, though, as it makes the generated
file non-portable.
Adding "magic" into probably security relevant features is problematic
and unless the engine is truly encoding-aware I'd abstain from such
changes.
johannes
Thread (20 messages)