Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:100199 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 17873 invoked from network); 13 Aug 2017 15:08:05 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Aug 2017 15:08:05 -0000 Authentication-Results: pb1.pair.com smtp.mail=cmbecker69@gmx.de; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=cmbecker69@gmx.de; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.21 as permitted sender) X-PHP-List-Original-Sender: cmbecker69@gmx.de X-Host-Fingerprint: 212.227.17.21 mout.gmx.net Received: from [212.227.17.21] ([212.227.17.21:52707] helo=mout.gmx.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id FF/DF-34801-35B60995 for ; Sun, 13 Aug 2017 11:08:04 -0400 Received: from [192.168.2.123] ([79.243.123.130]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MfBsk-1dwnS900YU-00OlNE; Sun, 13 Aug 2017 17:07:59 +0200 To: Nikita Popov , PHP internals References: Message-ID: <4ca2906e-4117-9773-d2bd-c17e27425a90@gmx.de> Date: Sun, 13 Aug 2017 17:08:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:W4qI2iSou8n2SV9ygG5Mbmm3udiis05w5MatWV4pA3CYnxi+hO2 qx740pq7sec8yW/oH+8mWwZHQ7nM/ohjPDhKrsKBnVopcBJQ1w3tG2AdTYVrbjH3Vc5s8bh zMgpeEZbadhPd/O6/1FbkXroi8QicrFDqdx45XyRfk458And9FqgpKdKzWA0Fvyb9SW/pCn rwE8vKpWTyZTnR52kdwhA== X-UI-Out-Filterresults: notjunk:1;V01:K0:HhnAMCDTEf0=:gTgVEBHE8RQ2HAoFjJTUeL NXWuldFTTfTn1J9G/ECpO8ecDtkJVTcht+NUaM6pMBLTDvTBiI7gz894FJ2gK10oxudg8ORWf O/XMbmUNnLn1TrbmiLplp1fsI9VOYfnoIVz607NmB/StMMfuald3aRZOTfGlUN7FiTBmOu8V8 vbMR9BYhOqjLkFUEF78Fd89zCCHFiJncc7qjPMxXo9N0QHL3RdJqtVcUnkP2zB+hkjYoZCifr 7/0l6HFkC6Fn+u2xA0GXT7tdQFq/mwh1MxS9LWZN2lvbr90lsvLBzarYDJ022o6DGb0sqwlxB t/IuxFWRGRvZmTaNedlgJ1uw084wPKe5iTyJarv5jo73WFvgh5CWWDCVKQCLlhvyqJsPX9+jy zu+EJnWcoVg3Y+uBNdcjteEiV55SB0vosT8v86zOP0ven8PE1r7nV+jOfeP5a3hcl7LgzOaMA HQ3dVWvFnnzA0X44YGo/Khk1XARhdY17rce+YxhvzCP3WhWHdCX40KbEw0s3Y5mDBKM7/mqfG hmLMPekkG8duzDU1OWnXsHYCgJ2DS1s6onZfcoJMVyx7F5/1o8fjyhsiC5j2nAWEz2HK9+CJO BogTWtzHVQSiZ5EV5QllCtrPzjDkjA7PdmhvYuuivVxAlPDK30lhRzDhs/m8xzszSZnqTHCRv FGMs4uCsbe2JV61Nf54KK5LPomLz38h24CAqM4tBV8J3P2jra8g3y7mDWcGDsVzOdUtozpVVe 5YT79OwmySCF6NMLsyJP+SoHiixhgzZIkCUD9U+a8N8VOR2fUuyfVzhC7emaOlEkTUoZ67Pem brOcPAAl6PAW9lRMMz/x1lmjKIIfIjHDQcn/+HEa7lQwOpDyn4= Subject: Re: WDDX serialization and security From: cmbecker69@gmx.de ("Christoph M. Becker") On 11.08.2017 at 15:15, Nikita Popov wrote: > Same question here as with unserialize(). > https://bugs.php.net/bug.php?id=75007 has recently been classified as not a > security bug, because WDDX should not be fed untrusted data. > > To provide some context here, our WDDX implementation is generally > vulnerable to object injection (it is possible to create arbitrary objects, > resulting in exploitable calls to __wakeup, __destruct, __toString and > similar), but it does not have the other security issues of unserialize (in > particular, no references). > > My question is now: What's the point of having this functionality at all? > As far as I can discern, WDDX seems to be targeted as a data interchange > format (something where trust generally cannot be assumed), but the way we > implement it (with support for object creation), it cannot be used as such. IMHO, implementing support for objects has been a most unfortunate decision, because WDDX was indeed not designed for that (). Considering https://bugs.php.net/bug.php?id=75044 makes the situation worse. > As such, these functions seem pretty useless right now. You can't use them > for data interchange due to security issues, and it's not the serialization > functionality you would use for local storage (for all it's issues, > serialize() is still a much better choice for that purpose.) ACK. > I'm wondering if it might be time to remove (i.e. deprecate and move to > PECL) the wddx extension? Hmm, that would leave a pretty useless extension in PECL. An alternative might be to remove support for objects and the wddx session serialization handler. This might even be done as bug fix if a respective ini option would be introduced. We could still move the extension to PECL afterwards. Anyhow, I've added a respective warning to the docs (http://svn.php.net/viewvc?view=revision&revision=342852). -- Christoph M. Becker