About 40 minutes before our WebSocket presentation at BayThreat I decided to do the final dry run. The slide with stacktrace of crashed desktop Safari caught my attention and I re-checked if there is still a problem. While current OSX Safari was fixed and I removed the slide, I decided to navigate to that page using Safari on my iPhone running IOS6.
The result was quite surprising, since I thought Apple is using the same webkit engine for all platforms: Safari simply hanged, while minimizing and re-opening caused a crash. Chrome on IOS6 behaved in similar way, while Chrome on OSX was always handling that code properly. Trying it on friends' Galaxy something caused the entire UI of Android to behave funny.
For those who are curious what the code is doing: it does nothing but trying to open several thousand WebSocket connections to non-existing server.
RFC 6455 is quite clear on this:
"There MUST be no more than one connection in a CONNECTING state. If multiple connections to the same IP address are attempted simultaneously, the client MUST serialize them so that there is no more than one connection at a time running through the following steps."
Most likely, mobile versions of popular browsers are just not implementing this policy, causing to either drain the file descriptors pool, or random number generator, or the memory.
This isn't a big deal, I just decided to document this in my blog to see how long would it take to port the policy to the mobile versions. As of today, January 6, the problem still exists, and the web page with deadly javascript is right here .
Recent Comments