Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66872
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5157AD1D.3020606@sugarcrm.com>
References: <5157A55A.1070507@sugarcrm.com>
	<CAAyV7nGtz94NaFdeQ4KL9X3_LX-dc=zbt35o=qoqd1zWGTFgaA@mail.gmail.com>
	<CAL+t6cF_pzrQtNSYMjCmxhm67QtbfhpEUiWx4xGWxAJpafrwkQ@mail.gmail.com>
	<5157AD1D.3020606@sugarcrm.com>
Date: Sun, 31 Mar 2013 20:36:38 +0200
Message-ID: <CAF+90c_BGKiRsNEk+JD15Pr2oSSR=NShkf-wFsZp2497J-RMhw@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Sherif Ramadan <theanomaly.is@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8fb20486ec6b3004d93cc89e
Subject: Re: [PHP-DEV] [RFC] more secure unserialize()
From: nikita.ppv@gmail.com (Nikita Popov)

--e89a8fb20486ec6b3004d93cc89e
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Mar 31, 2013 at 5:27 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> > I think Stas proposes a solution to the problem and I think Anthony
> > proposes a viable alternative. I would say that Anthony has found the
> > shortest distance between the two points (the problem and the solution),
> > however.
>
> The fact is that people do use serialize() for data that may be
> accessible by the user


Yeah, well, the people who do that are also the ones that are unlikely to
make use of the new parameters to secure themselves. In order to make them
use of the new feature they have to be explicitly educated about it and in
that case we can just as well educate them to use json_encode. In that
regard, I don't think this proposal is particularly useful.

JSON and serialize() are (inherently) different serialization formats with
different use-cases. The former is rather restricted and as such safe to be
provided by the user. The latter on the other hand aims at exactly
replicating the structure. Using the latter format for the former task is
in any case a bad idea. It's not like unserializing objects with dtors is
the only issue that can turn up. serialize() also supports references and
object-references, so one could probably use it quite easily to trigger
some kind of infinite loop/recursion in the application.

So, I personally don't see much value in this addition. Rather it could
provide people an excuse to use the function on user-provided data, which
is, as already mentioned, a bad idea. Even with this additional protection.
Also I'd like to point out that unserialize() in the past had a relatively
large number of different security vulnerabilities, so one should really,
really not trust it with data of unknown origin. Internal classes can quite
commonly be made to segfault with specially crafted serialization input.
E.g. the user might think that, hey, DateTime is a safe class, let's allow
unserializing that. Sounds legit doesn't it? Then let's remember those
various serialization bugs that were recently fixed in DateTime (or the
related classes, didn't really look at it). And then we would have a
potentially exploitable segmentation fault :)

Nikita

--e89a8fb20486ec6b3004d93cc89e--