Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72805
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.48 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <530C3C7B.8080907@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>
Date: Tue, 25 Feb 2014 19:36:11 +0900
Message-ID: <CAGa2bXYyxrLXxT812=s_s7zB+En1mfAJy9du90+Yt7OPZYjdvA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c27b2e81ef4804f338aaf3
Subject: Re: [PHP-DEV] Resolution for ver_export()/addslashes() encoding based
 script execution attack?
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c27b2e81ef4804f338aaf3
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Tue, Feb 25, 2014 at 3:47 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> > This is incorrect. PHP supports SJIS and others even in engine.
>
> I am not sure what kind of support you're referring to, what support the
> engine has for SJIS? Do you mean input filters? Those are just to read
> script code, AFAIK, aren't they?
>

Engine supports SJIS/other encoding script execution. Therefore,
addslashes()/var_export() behavior is security vulnerability just like
encoding based SQL/JavaScript injections.

Databases/browsers fixed these issues as vulnerability.

I think we need to face the fact that the scenario you are proposing is
> at least perceived as a rare case which is encountered in rare
> environment and is enabled by a shoddy code. Thus, proposing
> global-level engine changes for it are unlikely to gain consensus.
>
> Looking at the RFC, it makes claims of addslashes etc. being insecure,
> and other functions being insecure and unreliable, without giving proper
> examples and explanations of the context. I have a feeling that once
> people learn the context, they feel the claims in the RFC are
> overreaching and the solution proposed makes too many changes for the
> case that is perceived as too rare and need sloppy coding to enable.
>

Although, knowledgeable attacker would figure out how. I don't see the
point disclosing details of vulnerability in public before fixing it. It is
not a proper way to do. (I might have posted details in ML, though)

I would suggest to go back to the use case here and consider this:
> 1. Do we have a use case that is hard to handle in user's code?
>

Writing their own var_export() is not simple task.
In contrast, fixing them in PHP is easy by using mbstring.


> 2. What exactly makes it hard to handle - which capabilities for the
> user are missing? Is it access to certain information, certain
> algorithms, lack of knowledge?
>

Same as 1. Writing their own var_export() is not simple task.
addslashes()/var_export() do not recognize char encoding, just like old
database escape functions.


> 3. What is the minimal set of actions we'd have to take to make it
> easier? What is the set of actions that would cover 80% of user's needs?
>

Ideally, modifying addslashes()/var_export() is the best as users don't
have to change function name and no new functions.

Adding functions is the second. It close to modifying
addslashes()/var_export(), since it requires adding extra parameter.
However, there would be 2 codes mostly the same with this. The size of
duplicated code is not small. This is not good at all. It would be better
to pass function pointer internally. i.e. Pass function pointer to make it
multibyte aware.

I think once we have that, we have better chance at arriving at some
> resolution that would be more acceptable.


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
mind much disclosing details of attack method because it is well known to
certain people already, anyway.

I think I've posted enough info to security@php.net. Is it okay to post it
here?

Regards,

P.S. We are not users, but developers. We should consider only
consequences, i.e. number of affected users, like hood, etc do not matter.
 That said, resolution could vary. Even for fatal issue, we may choose to
document it as limitation if resolution is not feasible.

We have two feasible resolutions for this issue, change functions or add
new functions. IMO. Although, I would not suggest, we may ask users to
handle it by themselves.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c27b2e81ef4804f338aaf3--