# PHP 5.2.1 security issues

- Thread: https://externals.io/message/27944
- Original archive: https://news-web.php.net/php.internals/27944
- Started by Joe Orton on 2007-02-09T15:41:55+00:00
- Messages: 2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #27944 — Joe Orton — 2007-02-09T15:41:55+00:00

URL: https://externals.io/message/27944#27944

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

---

## #27945 — Ilia Alshanetsky — 2007-02-09T15:49:57+00:00

URL: https://externals.io/message/27944#27945 · In reply to: #27944

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