Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72804
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.163 as permitted sender)
Message-ID: <530C3C7B.8080907@sugarcrm.com>
Date: Tue, 25 Feb 2014 08:47:23 +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>
In-Reply-To: <CAGa2bXZcs-zq7afbY9dqvOcnQ0q1MAC0muO3VNSfxzMnL4_hCg@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!

> 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?

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.

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?
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?
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?

I think once we have that, we have better chance at arriving at some
resolution that would be more acceptable.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227