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