

PHP apps plagued by Mark of the Beast bug - _grrr
http://www.theregister.co.uk/2011/01/04/weird_php_dos_vuln/

======
yuvadam
TFA is plagued with technical inconsistencies, and generally looks like a
classic copy-paste job.

Either address a technical crowd, and use proper technical terms, or use plain
language anyone can understand.

"GET protocol"?

"adding a “-ffloat-store” flag to CFLAGS"??? Do they even know what this
means?

~~~
veb
It really sounds like someone needed something to write so they come to HN and
write a article based off what everyone in the thread has said without adding
anything of value.

~~~
AgentConundrum
The CFLAGS bit is almost a direct quote of this comment:
<http://news.ycombinator.com/item?id=2066352>

------
Udo
It's worth noting that a simple input-sanitizing _if_ statement applied across
the $_REQUEST variable can eliminate this vulnerability, a measure that every
PHP dev can use right now regardless of admin access to compile a new
executable.

Also, yesterday, there was a poster in here claiming that PHP's json_decode()
of an object like {"motb":"2.22507385851e-308"} would trigger the
vulnerability whether the number was enclosed in quotes or not. I have since
determined that this claim is false, json_decode() did not trigger the problem
with or _even without_ the quotes. In fact, the only way I was able to
reliably cause the crash was by casting variables from the $_REQUEST array as
float - a behavior that can be safeguarded against pretty easily.

Obviously, this is a serious issue, but it's an attack apps can be hardened
against with minimal effort. For comparison, a buffer overflow vuln on the
string type would be much, much more disastrous. So we're going to have to run
an extra line of input sanitization for a while, that's all.

~~~
RobertKohr
Would the code be:

    
    
      foreach($_REQUEST as $var=>$val){
         if($val=='22250738585072011')
            $_REQUEST[$var] = NULL;
      }

~~~
Udo
Exactly, only I'd suggest checking for the actual number (your example is
missing the exponent part) as well as for the non-scientific representation.
In my apps, I simply checked for the first 12 digits (ignoring the point)
only, worked pretty well. And I don't believe it's necessary to null the
value, prefixing it with something that prevents casting it as a double should
be enough (assuming you don't negate this later in your code).

~~~
RobertKohr
So the test would be:

    
    
      if(substr(str_replace('.', '', $val), 0, 11)=='22250738585'))
    

Feel free to post the test you do.

~~~
Udo
Yes, that's it. I'm on my mobile right now (sorry) so I can't exactly check my
code but as far as I can tell this was exactly the line. Sorry for not being
more helpful but I didn't want to post some untested code that I just typed on
a crappy touch screen...

------
dmoney
Is Mark of the Beast a common term for this type of bug (triggered by a
certain number)? Never heard it before.

~~~
Refringe
I haven't heard it used this this type of situation before, but I believe the
Mark of the Beast is commonly referenced as an "evil number", so I suppose it
works in this instance.

What it actually means: <http://en.wikipedia.org/wiki/Number_of_the_Beast>

