Your message dated Tue, 31 Jan 2012 14:41:07 +0100
with message-id <[email protected]>
and subject line Re: [php5] README.Debian.security: unclear reference to
unserialize() risk
has caused the Debian Bug report #639230,
regarding [php5] README.Debian.security: unclear reference to unserialize() risk
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
639230: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639230
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: php5
Version: 5.3.8-1
Severity: minor
README.Debian.security contains:
Most specifically, the security team will not provide
support for flaws in:
- problems which are not flaws in the design of php but can be problematic
when used by sloppy developers (for example: not checking the contents
of a tar file before extracting it, using unserialize() on
untrusted data, or relying on a specific value of short_open_tag).
It is unclear to me how using unserialize() on untrusted data would
create a particular risk. Do you perhaps mean extract()?
--- End Message ---
--- Begin Message ---
Hi,
> README.Debian.security contains:
> > Most specifically, the security team will not provide
> > support for flaws in:
> >
> > - problems which are not flaws in the design of php but can be
problematic
> > when used by sloppy developers (for example: not checking the contents
> > of a tar file before extracting it, using unserialize() on
> > untrusted data, or relying on a specific value of short_open_tag).
> It is unclear to me how using unserialize() on untrusted data would
> create a particular risk. Do you perhaps mean extract()?
README.Debian.security is designed to be a brief overview of what is
supported. Users that want to know more about *why* a certain technique
can be risky, can refer to the PHP manual. On the topic of unserialize(),
this writes:
"If the variable being unserialized is an object, after successfully
reconstructing the object PHP will automatically attempt to call the
__wakeup() member function (if it exists)."
which should clearly illustrate the risk with unserializing untrusted data.
Cheers,
Thijs
--- End Message ---
