Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:100247 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 48420 invoked from network); 17 Aug 2017 16:39:41 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Aug 2017 16:39:41 -0000 X-Host-Fingerprint: 2.24.106.64 unknown Received: from [2.24.106.64] ([2.24.106.64:28106] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4C/20-34801-BC6C5995 for ; Thu, 17 Aug 2017 12:39:41 -0400 Message-ID: <4C.20.34801.BC6C5995@pb1.pair.com> To: internals@lists.php.net References: <5d80894b-966f-e63c-4000-3fc0c8d2161b@gmail.com> Date: Thu, 17 Aug 2017 17:39:35 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46 MIME-Version: 1.0 In-Reply-To: <5d80894b-966f-e63c-4000-3fc0c8d2161b@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Posted-By: 2.24.106.64 Subject: Re: [PHP-DEV] Unserialize security policy From: ajf@ajf.me (Andrea Faulds) Hi, Stanislav Malyshev wrote: > Hi! > >> The two main points are: >> 1. While it's true that if you're using unserialize() on untrusted input >> you are most likely going to be vulnerable due to object injection, it may >> be quite hard for an attacker to exploit this for closed source > > Objects are not the problem (unless it's internal objects, in which case > the extension/code authors should have known better, but frequently > don't). References are huge problem, there are too many scenarios where > references can be made completely broken with bad serializing data. > >> 2. We should be able to precipitate most unserialize() bugs by regularly >> fuzzing it ourselves. The setup for doing so is also provided. > > That assumes that problems in unserialize() stem from some accidental > errors like off-by-one here and there. I don't think it's the case - I > think that given references support, it may not be possible to make it > robust against every hostile input without completely rewriting the > whole code, and even then I'm not sure it's possible. References can > create links between unrelated data items, which may lead to very subtle > problem with semantics inside objects, etc. which current code is just > not prepared to handle. > This is roughly how I feel about the matter also. I have wondered about whether it might be possible to rewrite unserialize() to be somewhat more resilient to reference issues. For example, making *every* value be unserialized as an IS_REFERENCE, rather than retroactively replacing non-reference values with reference values, could prevent use-after-free issues entirely. But it would also be slower and potentially expose a lot of issues elsewhere… -- Andrea Faulds https://ajf.me/