[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] php mb_ereg_replace()
From:       Christian Hoffmann <hoffie () gentoo ! org>
Date:       2009-05-13 16:39:45
Message-ID: 4A0AF7D1.60303 () gentoo ! org
[Download RAW message or body]


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@php.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


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]