Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72566
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAF+90c-OQfVX+X34ONwYOhmbvw6JQ_QYJ-k-ksE__B-sTD7jTA@mail.gmail.com>
References: <CAGa2bXaq+S8hhPW4Mx1KTWjhXk=OL+J5hHWoS-t0Q-5hJOxBow@mail.gmail.com>
 <CAF+90c-OQfVX+X34ONwYOhmbvw6JQ_QYJ-k-ksE__B-sTD7jTA@mail.gmail.com>
Date: Fri, 14 Feb 2014 06:42:57 +0900
Message-ID: <CAGa2bXbm3=yT63XY_=_Ze8Q2VGT4JKOixKpZQg4O33BdODtAMQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01493dbe0002c204f25095b2
Subject: Re: [PHP-DEV] [VOTE] Multbye char handling - Remove vulnerability
 related to multibyte short and long term
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e01493dbe0002c204f25095b2
Content-Type: text/plain; charset=UTF-8

Hi Nikita,

On Fri, Feb 14, 2014 at 6:14 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> I voted no on both RFCs, for about the same reasons as Joe. Voting on
> mbstring-ng at this point makes about zero sense, given that the code is
> nowhere even near being ready for merging into PHP.
>
> Regarding the other RFC for the addition of new mb_* function, I'd like to
> start off by saying that I disagree with your premise that this is a
> security vulnerability that needs to be fixed quickly and across all
> supported versions. As far as I can see the issue is somebody using
> addslashes() in an inappropriate context - this is a vulnerability in the
> application, not PHP. This is a lot like saying that we have an RCE
> vulnerability in eval() because someone had the genius idea of putting
> eval($_GET['str']) in his or her code.
>
> As this constitutes no critical or non-critical vulnerability in PHP, any
> function additions should only happen in PHP 5.6 and not PHP 5.4+.
>
> Apart from this, the RFC is very low on technical detail. It doesn't have
> a patch, which is not a problem *per-se*, however it doesn't have any
> implementational details whatsoever. While I guess that the addslashes part
> is rather straightforward, I'm sure that addcslashes, escapeshellarg and
> var_export are less trivial.
>
> An example of what is unclear: The addclashes functions has a charlist
> parameter. Currently chars with ASCII <32, >126 are encoded in octal - what
> will happen here with multibyte chars? Will you encode the unicode code
> point in octal? Are there even systems that support that? And what about
> the range feature? Will this cover unicode code point ranges now? Etc.
>
> This RFC probably has merit, but right now there is not enough detail to
> make an informed decision.
>

Very informative comment. Thank you!

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--089e01493dbe0002c204f25095b2--