Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66883
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.91 as permitted sender)
Message-ID: <5159DD93.1010105@sugarcrm.com>
Date: Mon, 01 Apr 2013 12:18:43 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Nikita Popov <nikita.ppv@gmail.com>
CC: Sherif Ramadan <theanomaly.is@gmail.com>, 
 PHP Internals <internals@lists.php.net>
References: <5157A55A.1070507@sugarcrm.com> <CAAyV7nGtz94NaFdeQ4KL9X3_LX-dc=zbt35o=qoqd1zWGTFgaA@mail.gmail.com> <CAL+t6cF_pzrQtNSYMjCmxhm67QtbfhpEUiWx4xGWxAJpafrwkQ@mail.gmail.com> <5157AD1D.3020606@sugarcrm.com> <CAF+90c_BGKiRsNEk+JD15Pr2oSSR=NShkf-wFsZp2497J-RMhw@mail.gmail.com>
In-Reply-To: <CAF+90c_BGKiRsNEk+JD15Pr2oSSR=NShkf-wFsZp2497J-RMhw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] more secure unserialize()
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> 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

Why? Making use of one parameter is orders of magnitude easier than
refactoring your whole application to not use serialize() (especially if
you need object support).

> exactly replicating the structure. Using the latter format for the
> former task is in any case a bad idea. It's not like unserializing

You completely ignore situations where two could mix - i.e. where you
could store data that can potentially be not reproducible by JSON and
still may - due to some or other oversight - be controlled by the user.
That's why security has layers - so that if you make mistake on one
layer, other layer would limit the exposure. That's why you don't run
you webserver as root - even though you could just say "we shouldn't
have remote execution holes, so it doesn't matter under which user the
webserver runs". You seem to be under impression that if particular
technique solves particular problem, there shouldn't be any security
measures protecting you if you do not use that technique. I think it is
plain wrong approach to security.

> 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 :)

I don't see how this has anything to do with anything. There are tons of
different bugs, and I never claimed this patch protects against all of
them, so if you think somehow finding a scenario that this change does
not protect from invalidates it, then by the same logic we should never
have any security features at all that do not make the application
perfectly secure in the hands of most ignorant user.
The point is not to make perfect protection, the point is to make common
scenario safer and more resistant to common attacks that happen to
existing applications all the time now.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227