Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:75062 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 9947 invoked from network); 24 Jun 2014 19:05:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Jun 2014 19:05:46 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.75 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.75 smtp75.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.75] ([108.166.43.75:48364] helo=smtp75.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E2/7E-39652-90CC9A35 for ; Tue, 24 Jun 2014 15:05:46 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 2EB9B183BE1; Tue, 24 Jun 2014 15:05:43 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp2.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id D1ECF183BFE; Tue, 24 Jun 2014 15:05:42 -0400 (EDT) Message-ID: <53A9CC06.5060707@sugarcrm.com> Date: Tue, 24 Jun 2014 12:05:42 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nikita Nefedov , "internals@lists.php.net" References: <53A1C722.9060501@fedoraproject.org> <53A21137.6010705@sugarcrm.com> <53A2A9BD.1070603@sugarcrm.com> <53A3874E.20704@sugarcrm.com> <53A65578.6000701@sugarcrm.com> <53A8626B.701@fedoraproject.org> <53A866B6.4060501@sugarcrm.com> <53A92B24.40706@fedoraproject.org> <53A92F93.2060507@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: Bug 67072 resolution for 5.4/5.5 From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > I don't see any problem in the fact that you can skip actual instantiation > of the object. Even if there *is* a problem with that - a lot of user-land The problem is remotely-triggerable DoS and potentially RCE. Not sounding bad enough? > code already uses this trick and it will be a pretty big BC break (as we The mere fact O: works for custom serializer objects is a clear bug. It should have never worked, it was never documented as working and nobody ever promised anybody it would work. It is unfortunate that userland code relies on a bug to be working, but this particular bug is too dangerous to keep in. Yes, BC is important. Not having remotely-triggerable memory corruption is more important. > million times already. Using input data blindly is user's mistake. I think Sorry, you can not bursh it off in this case as "user error". The case where unserializer crashes on wrong data is a bad problem - and there's absolutely no way for the user to filter the data to ensure it does not happen, except for implementing completely custom unserializer. The only way is to completely abandon usage of serialize(). This is not a good solution to propose to people with existing apps. > there are already cases of PHP trying to 'secure' users from themselves > (hello magic quotes). And I think all we have to do is to prevent How magic quotes have anything to do with it? MC failed because it didn't work and was applied in proper place, not because it didn't allow you to trigger crashes and UMRs whenever you'd like. We give people plenty of the rope, but there should be some limit. I think remotely-triggerable crashes go beyond the limit. > possibility of segfault, not the possibility of instantiation of the > object (without calling internal constructor) itself, because skipping > constructor (for whatever type classes - internal or user-land) has its > use cases. I'd like to question this - the whole meaning of ctor is to initialize the object and if you need to routinely skip it the problem is probably elsewhere. But this is a topic for another discussion. > Don't you think that it would be better, instead of preventing creation of > the objects without calling internal constructor, to prevent calling any We're not preventing this right now. We're preventing using serializer for doing this, because it does not work. If there's another way of doing this without causing breakage, then fine, do it. Let's have an RFC about it and discuss it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227