Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72806
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.147 as permitted sender)
Message-ID: <530C77F8.2060809@sugarcrm.com>
Date: Tue, 25 Feb 2014 13:01:12 +0200
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <CAGa2bXYO=Q3pmYKYOt0qudFtzimrXitJoLcB4KZ80MYJ-nJo0A@mail.gmail.com> <CAF+90c9umjqfiW3780hPjk_LpbyV=fT2t=bXZxWhiSDN-yuiuA@mail.gmail.com> <CAGa2bXZcs-zq7afbY9dqvOcnQ0q1MAC0muO3VNSfxzMnL4_hCg@mail.gmail.com> <530C3C7B.8080907@sugarcrm.com> <CAGa2bXYyxrLXxT812=s_s7zB+En1mfAJy9du90+Yt7OPZYjdvA@mail.gmail.com>
In-Reply-To: <CAGa2bXYyxrLXxT812=s_s7zB+En1mfAJy9du90+Yt7OPZYjdvA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Resolution for ver_export()/addslashes() encoding based
 script execution attack?
From: smalyshev@sugarcrm.com (Stas Malyshev)

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