Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72791
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXYO=Q3pmYKYOt0qudFtzimrXitJoLcB4KZ80MYJ-nJo0A@mail.gmail.com>
References: <CAGa2bXYO=Q3pmYKYOt0qudFtzimrXitJoLcB4KZ80MYJ-nJo0A@mail.gmail.com>
Date: Mon, 24 Feb 2014 12:07:05 +0100
Message-ID: <CAF+90c9umjqfiW3780hPjk_LpbyV=fT2t=bXZxWhiSDN-yuiuA@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c306f0cddf4404f324f871
Subject: Re: [PHP-DEV] Resolution for ver_export()/addslashes() encoding based
 script execution attack?
From: nikita.ppv@gmail.com (Nikita Popov)

--001a11c306f0cddf4404f324f871
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Feb 24, 2014 at 10:41 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi all,
>
> Since this RFC is declined,
>
> https://wiki.php.net/rfc/multibyte_char_handling
>
> We need another short term resolution for it at least.
> Any suggestions?
>

Quoting from another thread:

> 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.

There is no vulnerability here as far as PHP is concerned. As such there is
no need for a short term resolution.

Nikita

--001a11c306f0cddf4404f324f871--