Re: Resolution for ver_export()/addslashes() encoding based script execution attack?

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. > 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. > Databases/browsers fixed these issues as vulnerability. Which "these issues"? Databases and browsers don't have var_export() function. > Although, knowledgeable attacker would figure out how. I don't see the > point disclosing details of vulnerability in public before fixing it. It We can take it to security list if you think it's too sensitive, or in private bug. But if we have RFC that say var_export() "lacks proper multibyte handling" but doesn't say what is expected from it, it's hard to accept it. > Writing their own var_export() is not simple task. > In contrast, fixing them in PHP is easy by using mbstring. Why would one need to write their own var_export? What are "them" that are easy to fix by using mbstring? > addslashes()/var_export() do not recognize char encoding, just like old > database escape functions. OK, this is a bit more. Why var_export needs to "recognize char encoding" and what it means for var_export to "recognize char encoding"? > Regarding details of this issue, I just think it's not right thing to do > disclosing detail of fatal vulnerability before fixing. However, I don't I think many people (myself included) do not see "fatal vulnerability" being there. If you have some details and feel it's not good to disclose it you could send it to security@php.net or privately to me or open private bug. Since I don't know what these details are I rely here on your judgement. > I think I've posted enough info to security@php.net > <mailto:security@php.net>. Is it okay to post it here? Yes, but I don't remember the details about var_export, etc. there. Maybe I missed the email, could you forward it to me privately then? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227