Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72814
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.176 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <530C77F8.2060809@sugarcrm.com>
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>
 <530C77F8.2060809@sugarcrm.com>
Date: Wed, 26 Feb 2014 14:25:45 +0900
Message-ID: <CAGa2bXZFopwiKWOE0A32OgGRPfskBsgj+MutJfom1wAmODskvA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c367803152f204f3487254
Subject: Re: [PHP-DEV] Resolution for ver_export()/addslashes() encoding based
 script execution attack?
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c367803152f204f3487254
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Tue, Feb 25, 2014 at 8:01 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> > 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.
>

There is basic realization issue. There is a class of attack referred as
encoding based attack. Basic principle is the same regardless of
system/program.

All injection attacks are involves with instruction and data. Injection
attacks are attack that injects instruction to data. e.g. buffer overflow,
javascript  injection, sql injection, etc. Encoding based attacks are used
for text interface systems that supports certain encoding with certain
escape method. Notably, SJIS/etc and \ escape.


> 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.
>

I think you've missed my mails in security@php.net.

 > 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?
>

var_export() and other functions listed in the RFC.


>
> > 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"?
>

var_export() and others have to recognize char encoding to perform escaping
properly.


>
> > 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.
>

If attacker provided script execution is not a fatal, what would be fatal?


>
> > 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?


No problem. I'll find and send it later.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c367803152f204f3487254--