HN Explorer

11 comments

[ 617 ms ] story [ 1044 ms ] thread
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.
[dead] dsghrtkty
=== http://ta.gg/4wt ====

=== http://ta.gg/4wt ====

=== http://ta.gg/4wt ====

=== http://ta.gg/4wt ====

=== http://ta.gg/4wt ====

=== http://ta.gg/4wt ====

=== http://ta.gg/4wt ====

=== http://ta.gg/4wt ====

Gold autumn, personality Men’s clothing Shoes, Travel bag that grabs an eye coat Chao packet Free transport

=== http://ta.gg/4wt ====

=== http://ta.gg/4wt ====

=== http://ta.gg/4wt ====

=== http://ta.gg/4wt ====

=== http://ta.gg/4wt ====

=== http://ta.gg/4wt ====

=== http://ta.gg/4wt ====

=== http://ta.gg/4wt ====

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.