Re: [VOTE] Multbye char handling - Remove vulnerability related to multibyte short and long term
Hi Nikita,
On Fri, Feb 14, 2014 at 6:14 AM, Nikita Popov <[email protected]> wrote:
> I voted no on both RFCs, for about the same reasons as Joe. Voting on
> mbstring-ng at this point makes about zero sense, given that the code is
> nowhere even near being ready for merging into PHP.
>
> Regarding the other RFC for the addition of new mb_* function, I'd like to
> start off by saying that I disagree with your premise that this is a
> security vulnerability that needs to be fixed quickly and across all
> supported versions. As far as I can see the issue is somebody using
> addslashes() in an inappropriate context - this is a vulnerability in the
> application, not PHP. This is a lot like saying that we have an RCE
> vulnerability in eval() because someone had the genius idea of putting
> eval($_GET['str']) in his or her code.
>
> As this constitutes no critical or non-critical vulnerability in PHP, any
> function additions should only happen in PHP 5.6 and not PHP 5.4+.
>
> Apart from this, the RFC is very low on technical detail. It doesn't have
> a patch, which is not a problem *per-se*, however it doesn't have any
> implementational details whatsoever. While I guess that the addslashes part
> is rather straightforward, I'm sure that addcslashes, escapeshellarg and
> var_export are less trivial.
>
> An example of what is unclear: The addclashes functions has a charlist
> parameter. Currently chars with ASCII <32, >126 are encoded in octal - what
> will happen here with multibyte chars? Will you encode the unicode code
> point in octal? Are there even systems that support that? And what about
> the range feature? Will this cover unicode code point ranges now? Etc.
>
> This RFC probably has merit, but right now there is not enough detail to
> make an informed decision.
>
Very informative comment. Thank you!
Regards,
--
Yasuo Ohgaki
[email protected]
Thread (11 messages)