Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72883
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.169 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <5310DC19.2050107@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> <1393328380.5233.45.camel@guybrush>
 <530DD588.1000407@sugarcrm.com> <CAGa2bXa_kYvqKz_6imjFPb0KLuKJzVJEgTHKmrWG7kH75eQnHQ@mail.gmail.com>
 <5310DC19.2050107@sugarcrm.com>
Date: Sat, 1 Mar 2014 09:19:41 +0900
Message-ID: <CAGa2bXaB+SVF7chKxOnwMPzkdafwa0P4gdvEWKfvv8FBz1UF-Q@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>, Pierre Joye <pierre.php@gmail.com>
Cc: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@schlueters.de>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c248962669f204f38085bd
Subject: Re: [PHP-DEV] Resolution for ver_export()/addslashes() encoding based
 script execution attack?
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c248962669f204f38085bd
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Sat, Mar 1, 2014 at 3:57 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> > PHP supports SJIS and the like. Escape functions should provide safe
> > escaping like databases. The only way to solve this issue is encoding
>
> You are making global claims which sound plausible on surface, but when
> you put them in context, it gets much more complicated. PHP supports
> SJIS, yes - just as it supports any other existing encoding. That does
> not mean every scenario possible is automatically working or can be made
> to work consistently. Specifically, SJIS encoding is not compatible with
> ASCII encoding, which means same function with same parameters would not
> work, moreover - choosing parameters which would work in every situation
> may be quite problematic.
>

It seems your are trying to solve issue in a way of cannot be solved.

To eliminate encoding based attacks, proper use of encoding is mandatory.
Leaving encoding setting automagic would be cause of issues. Example is use
of locale for deciding encoding in programming language. (Note: use of
locale is not always bad choice. It's good enough for applications in many
cases, but it's bad in programming language in general.)

There are many lessons with databases/browsers in past years. Why not adopt
it for PHP?


>
> > aware escape which databases adopted years ago. I'm proposing known
> > vulnerability with known method to fix.
>
> Encoding-aware inside PHP means different thing than inside the
> database. The database has only one encoding within the session and
> doesn't have to deal with anything else. PHP has much more to deal with,
> especially in scenarios you are proposing - where you are writing out
> PHP scripts to be executed later. Your solution assumes one set of
> environment settings and will break in another, current solution works
> in one set of environment settings and will break in another. So I'm not
> sure we'll be making much of an improvement there by switching set of
> cases where it will break.
>

Like database users may have multiple connections at once and should know
what the encoding for each connection, PHP users can use multiple exported
PHP scripts with multiple encodings and PHP users should know what the
correct encoding for a script. There is a way to handle this situation
properly now. declare(encoding='NAME');

What I would like to fix is design bug of encoding support. There should be
encoding aware escape/unescape if various encodings are supported,
otherwise we open hole to attacker.


>
> > BTW, users who do not have to worry about this are not affected by
> > proposed change.
>
> That is not the reason to accept the change. It is a necessary, but not
> a sufficient condition for acceptance.


Necessity is clear. There is situation that attackers could execute their
script with PHP supported encoding. This is fatal bug. Counter measure is
also clear. Use of encoding aware function is mandatory. Therefore, all we
have to discuss is "implementation of encoding aware escaping/unescaping
functions".

Please note that it does not matter at all if PHP is going to support UTF-8
as internal character encoding or not. Encoding aware escape/unescape is
mandatory regardless of internal UTF-8 support because this is a issue of
input/output. i.e. If PHP could handle I/O properly or not.

Let's make it simple.
 - There is issue (code execution by attacker).
 - There is solution (encoding aware escape/unescape).
 - There are 2 feasible resolutions (modify existing function or add new
function)
 - Proper implementation may vary. (what we should discuss)


To Pierrie,

I'll post (or create new RFC) to explain details of encoding based attacks.
Knowledge about encoding based attack is mandatory for Unicode support
also.

Any more comments for disclosing attack details at point?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c248962669f204f38085bd--