Re: PHP and some == wonkiness

[mancha <mancha1 () zoho com>]

On Tue, May 05, 2015 at 08:53:42AM +0200, Florian Weimer wrote:
> On 05/04/2015 08:34 PM, Pádraic Brady wrote:
>
> > It all boils down to PHP loose typing/type juggling for == and
> > strict type comparison for ===. The first option will trigger a set
> > of rules capable of converting strings into floats or integers,
> > based on whether both strings are representative of a float (i.e.
> > your example), or where one of the values being compared is already
> > an integer/float. Unfortunately, it is indeed a common weakness to
> > not use strict comparisons in security related code. For example,
> > Laravel had a recent issue in comparing CSRF tokens where passing in
> > a zero always passed the check from this mistake,
>
> Oh.
>
> But the current case apparently needs a string from a very specific
> set.  Do we know the digests which trigger this?  If it has to be "0e"
> followed by only digits on both sides, it is somewhat unlikely that
> you have a reference string with this property, especially if SHA-1 is
> used (around 6.84×10¯¹¹, if I'm not mistaken).
>
> -- Florian Weimer / Red Hat Product Security

This can happen more frequently than you think.

Taking sha1 as our reference hash and "==" as our equivalence relation:

All [a-f][0-9a-f]{39} are in equivalence class A.

All 42[a-f][0-9a-f]{37} are in equivalence class B.

Note: those regexes aren't representative of the full equivalence
classes because prepending 0s doesn't alter the value (i.e.
0[a-f][0-9a-f]{38} is in equivalence class "A" as well..

Et cetera.

--mancha

Attachment: _bin
Description: