Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71210
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.52 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <1389976678.2057.8.camel@smugmug>
References: <CAGa2bXauxj6Sca8qYk2cxQ=TeG4bjWgcv-Aqy3cJe35ap72Yfw@mail.gmail.com>
 <CAF+90c-ZgsCczU71TJap1yeaNhKgQeoUR5oLKwwHHaoOD8z_ig@mail.gmail.com>
 <CAGa2bXb6jLX8HMN-rL7t5j5R_0SaeRkd5r4_MrmQFfsJxxaSxQ@mail.gmail.com> <1389976678.2057.8.camel@smugmug>
Date: Sat, 18 Jan 2014 04:53:58 +0900
Message-ID: <CAGa2bXYkev19UPMGvYH=-OhW3og890OSuRB4dzC3EhejJ_rFrA@mail.gmail.com>
To: Mike <mike.php.net@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b342f86815e3004f02fe96a
Subject: Re: [PHP-DEV] [RFC] Multibyte char handling
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--047d7b342f86815e3004f02fe96a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Mike,

On Sat, Jan 18, 2014 at 1:37 AM, Mike <mike.php.net@gmail.com> wrote:

> On Fri, 2014-01-17 at 07:34 +0900, Yasuo Ohgaki wrote:
>
> > This discussion circulate discussion.
>
> I'm also in favor of putting those things in ext/mbstring.
>

I'll make this a vote option.


>  >
> > At first, I proposed locale based solution using php_mblen().
> > This approach does not require additional encoding parameter
> > since encoding is specified by locale.
>
> Meh, but would be okay for me.
>

It's feasible solution for older versions.
I would like to remove locale based code for future releases, though.

Functions that are using php_mblen() could be modified to use mbstring
when PHP is built with mbstring. Functions may use internal_encoding.

Use of internal_encoding requires user code modification in some cases.
For instance, Japanese Windows command line uses Shift_JIS as
terminal encoding while many users uses UTF-8 for script. Users has to
add code that changes internal_encoding. e.g.
escapeshellarg()/escapeshellcmd().
They could use simple wrapper for escapeshellarg()/escapeshellcmd(), though=
.

Although users have to modify their code a little, fgetcsv() and like would
be more usable because it's more reliable than locale.

It may be better to add mb version of these functions and deprecate them
like addslashes(), if we are not going to modify these functions.

 >
> > However, some people don't like the solution (in security ML)
> > because it is  locale based solution. It may have unwanted side
> > effects. Locale is unreliable and most user just don't care about it.
> >
> > Therefore, I proposed this approach that introduce encoding
> > parameter just like htmlspecialchars()/htmlentities().
> >
> > Encoding parameter (or some way to specify encoding) for security
> > related string function is mandatory. We should provide some way
> > to specify encoding.
> >
>
> Many of us do not have access to that mailing list, so yould you shed
> some light on the acutal issue?
>

There are 2 classes of security issue in php_addslashes()

First  is PHP script execution.
Suppose this is a script save app config script.

<?php
$v =3D addslashes('=E8=A1=A8') . addslashes('\'; exec(\'rm -rf /\'); die();=
\''));
file_put_contents('myconfig.php', '<?php $config=3D'.$v);
?>

then read it as PHP script.

<?php
include 'myconfig.php';
// other code follows
?>

If '=E8=A1=A8' is SJIS, the char code is 0x955c (0x5c =3D \). Since addslas=
hes() is
not multibyte aware, it escapes
the char as 0x95, 0x5c, 0x5c. This make possible that break out string
quoting and write attack code.

The contents of myconfig.php became

<?php $config=3D '=E8=A1=A8'; exec('rm -rf /'); die()

with SJIS, BIG5 and other similar encoding.

var_export() can be attacked by the same reason and method.
This attack method is well known for attackers around East Asia region,
but it's not limited to East Asia.


Second is rather obvious. It's a DoS.
Since Zend engine raise compile error for invalid encoding, data generated
by addslashes()/var_export() could stop script execution.

For instance,
http://lxr.php.net/xref/PHP_5_5/Zend/zend_language_scanner.l#507


Although it would be rare in real code, php_stripslashes() could be
problematic.
Since some chars have special byte in SJIS like encoding, it could be used
to remove escape character and cause problem. If stripped string is
evaluated
as PHP script, it may cause issues like php_addslashes().


Anyway, there isn't a feasible solution that could satisfy all. AFAIK.
Many users don't have to update their code, but some users may have to
modify
their code according to their usage.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--047d7b342f86815e3004f02fe96a--