Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 5 May 2015 07:26:42 +0000
From: mancha <>
Subject: Re: PHP and some == wonkiness

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.


Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Your e-mail address:

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

Powered by Openwall GNU/*/Linux - Powered by OpenVZ