PHP apps plagued by Mark of the Beast bug | Hacker News Reader

PHP apps plagued by Mark of the Beast bug

theregister.co.uk

17 points_grrr10 comments

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?

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.

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

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.

Would the code be:

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

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).

So the test would be:

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

Feel free to post the test you do.

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

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

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

Reply on news.ycombinator.com