Date: Wed, 13 May 2009 18:39:45 +0200
From: Christian Hoffmann <hoffie@...too.org>
To: oss-security@...ts.openwall.com
Subject: Re: php mb_ereg_replace()

On 2009-05-13 16:47, Steven M. Christey wrote:
> We don't have a CVE for the fact that strcpy() exists - it can be used
> safely even though it's dangerous.  My interpretation of this issue was
> the same, so no CVE is needed.  Any PHP application that misuses
> mb_ereg_replace(), however, is fair game.
> 
> (We already have a handful of CVEs for executable regexp's in PHP apps)
While I'm fine with no CVE being assigned, I think the difference
between those cases should be clearly noted. Writing secure preg_replace
calls (which make use of the 'e' modifier) is one thing and rather easy
to accomplish (that's probably what you are referring to -- apps failing
to do that).
In contrast to that, writing secure mb_ereg(i)_replace calls which deal
with user data becomes probably a real mess (you have to escape the
input string before passing it to the function, it is impossible to come
up with an mb_ereg_replace call which can be considered secure without
doing any escaping beforehand).

Short example:
Run the code from comment "[9 May 5:13am UTC] jani@....net" from [1].
The result clearly shows the difference between mb_ereg_replace() and
preg_replace() and how hard it would be to write secure code involving
this function, the 'e' modifier and untrusted input:

$ php bla.php
mb_ereg_replace()
THIS SHOULD NOT BE SEEN!!
string(0) ""
string(0) ""

preg_replace()
string(12) "', test(), '"
string(0) ""


Anyway, doesn't change anything regarding the fact that nothing has to
be done CVE-wise, imo.


[1] http://bugs.php.net/bug.php?id=48180

-- 
Christian Hoffmann
Gentoo PHP team


[ CONTENT OF TYPE application/pgp-signature SKIPPED ]

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Hosted by DataForce ISP - Powered by Openwall GNU/*/Linux