PHP 5.2.1 security issues

Joe,

I am reluctant to disclose more information about the particulars of
the issues so soon after the release, without giving a change for
people to upgrade to it first. Once a month or so passes, I'd be
happy to provide you, or anyone else interested with additional
information about the specifics of the fixes. Although I suspect the
MOPB planned by Stefan in March will identify most of the resolved
issues with lots of detail.

Hi, I'm looking through the list of security issues listed in the
5.2.1
release notes; trying to work out what the impact of these issues
is so
we're able to explain to our users how they are affected.

Could anyone help clarify a few of the items listed?

• Fixed allocation bugs caused by attempts to allocate negative values
  in some code paths

I presume this refers only to the numerous emalloc->safe_emalloc
changes, is that correct?

• Fixed unserialize() abuse on 64 bit systems with certain input
  strings

The only change to the unserializer in 5.2.1 that I can find was to
add
support for the "S:" token type; this doesn't seem security-
related. Is
there something I missed here? Was it a fix to the generated parser
code rather than the grammar/sources?

• Fixed a possible buffer overflow inside mail() and ibase_
  {delete,add,modify}_user() functions.

The only change to mail() was:

http://cvs.php.net/viewvc.cgi/php-src/ext/standard/mail.c?
r1=1.87.2.1.2.1&r2=1.87.2.1.2.2&diff_format=u

I can't see how the old code could present a security issue here.

There were no changes to the sqlite extension per se, but the
change to
the bundled copy of the sqlite library looks like like a buffer
overrun
fix:

http://cvs.php.net/viewvc.cgi/php-src/ext/sqlite/libsqlite/src/
encode.c?r1=1.5.4.1&r2=1.5.4.1.2.1&diff_format=u

or am I missing something else? (so, any user who configures using an
external copy of sqlite2 would still be vulnerable to that issue)

Regards,

joe

--

Ilia Alshanetsky