Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103884
MIME-Version: 1.0
References: <CAF+90c-GfwWSJ+LUUYrb6gpZRrwP=XX=hWFD9DL-3xQhBOgp+A@mail.gmail.com>
In-Reply-To: <CAF+90c-GfwWSJ+LUUYrb6gpZRrwP=XX=hWFD9DL-3xQhBOgp+A@mail.gmail.com>
Date: Wed, 30 Jan 2019 10:20:11 +0100
Message-ID: <CAOWwgpm3Ne74swRBhvEXO=rqps_GrAYMKbQzKxzjNHSttkekFA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000077b3f10580a96b66"
Subject: Re: [RFC] New custom object serialization mechanism
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--00000000000077b3f10580a96b66
Content-Type: text/plain; charset="UTF-8"

Hi Nikita,

https://wiki.php.net/rfc/custom_object_serialization
>

In the RFC, you mention that "Executing arbitrary code in the middle of
unserialization is dangerous and has led to numerous unserialize()
vulnerabilities in the past. For this reason __wakeup() calls are now
delayed until the end of unserialization."

How about destructors?
Some vulnerabilities come from destructors doing things with unserialized
state.
Would it be possible/a good idea to *not* call any destructors unless the
"wakeup" stage has been successful? Any exceptions thrown during
__wakeup/__unserialize would mean the unserialized data structure should be
destroyed without calling any destructors?
WDYT?

Nicolas

--00000000000077b3f10580a96b66--