リンクをクリックするだけでiOSデバイスが再起動してしまうWebサイト 14
意図的なものとバグのものと 部門より
リンクをクリックするだけでiOSデバイスが再起動してしまうというWebサイト「crashsafari.com」が話題となっている（VentureBeat、9to5Mac、Guardian、BetaNews）。
crashsafari.comはHTML5のhistory.pushState()メソッドを使い、履歴に1文字ずつ長いURLを繰り返し追加していくことでWebブラウザをクラッシュさせるというもの。名前の通り、Safariが最も大きな影響を受け、iOSのSafariでは端末が再起動してしまう。再起動までの時間は端末の処理速度によって異なるようだ。OS XのSafariは応答しなくなり、再度使用できるようにするにはMacの再起動が必要だという。
ChromeやOpera、FirefoxなどのWebブラウザも影響を受ける。ChromeとOperaはリンクをクリックすると応答しなくなり、放置しておくとクラッシュする。手元の端末で試してみたところ、Androidではタブがクラッシュし、Windowsではメインプロセスのメモリ使用量が4GB近くなったあたりでアプリ自体がクラッシュした。いずれも完全に応答しなくなるわけではなく、クラッシュ前にタブやアプリを閉じることは可能だった。ただし、環境によって動作が異なる可能性もある。
一方、Firefoxは応答しなくなるものの、しばらくすると応答のないスクリプトの警告が表示される。「スクリプトを停止」をクリックしてもスクリプトは停止しないが、「スクリプトをデバッグ」をクリックすることでスクリプトを停止することができた。警告が表示された時点でメモリが解放されるようなので、クラッシュすることはないものとみられる。 なお、Internet ExplorerとEdgeでは一時的にCPU使用率が高くなるものの、何事もなくWebページが表示される。URLにセットできる文字数が制限されていて、エラーによりスクリプトが停止するようにも見える。 VentureBeatの調べによると、このWebサイトのドメインが登録されたのは昨年4月だが、最近になってHacker Newsへリンクが投稿されたことで再び話題になった模様。また、「crashchrome.com」というのもあるようだ。
なお、これとともにアドレスバーで検索を行うとブラウザが突然終了するという問題も発生していたという（ロイター）。こちらは検索候補を表示する機能が原因のようだが、すでに修正が行われているとのこと（BuzzFeed）。
リソース次第では耐えられる？ (スコア:0)
<script>
var total = "";
for( var i = 0; i < 100000; i++ ) {
total = total + i.toString();
history.pushState(0,0, total );
}
</script>
Re: (スコア:0)
なぜたった100000で攻撃の手を緩めているのやら？
Re: (スコア:0)
もともと冗談 [applech2.com]らしいので。
Re: (スコア:0)
ブラクラ再来か？
てかIEでこういったコード動かすと警告出なかったかな？
♯ラズパイのOS落としてるので今試せん
Windowsでもクラッシュ (スコア:0)
Windowsでもクラッシュするということは、メモリ確保に失敗したのに
エラー処理をせずに未確保領域を使用してしまっているということ？
Re:Windowsでもクラッシュ (スコア:2)
(´･ω･｀)しらんがな。
読書き無しでも、割当失敗で即例外を吐いて死ぬっていう実装は、割とよくある。
Re: (スコア:0)
チェックしたら遅くなるだろ
Re: (スコア:0)
ioのエラーかもよ。実装次第だけど。pushstateはセッション履歴だけど、モダンブラウザはセッション履歴もローカルファイルに書き込む(=クラッシュした時やり直せるように)から、通信時間がゼロな分、DOS系としては割と脆弱になりやすい。(関係者談)
Re: (スコア:0)
メモリ確保に失敗したらリカバリは原則不可能だからね。
メモリ切れになると例外を動かすメモリがない可能性があるし。
一部の高信頼性が必要な機器は対策してるかもしれないけど。
Re: (スコア:0)
Firefoxの場合だと(プロジェクトが古いので例外の使用を禁止している関係もあるけど)infallible allocatorという、割り当てに失敗したらその場でクラッシュするアロケーターを原則として使って、明らかに失敗する可能性が高そうな割り当て(大量のグラフィックメモリの確保とか)だけ、個別に失敗をチェックできるアロケーターを使っている。
ただしこれはGeckoの場合なので、iOS版では単にSafariと同じWKWebKitのバグを踏んでいるだけだと思う。
Re: (スコア:0)
うろ覚えだが、以前Becky!の開発者が、「復旧不可能な問題が起きたらアプリをクラッシュさせるのが一番安全だ」と言ってた記憶がある。
例えばメモリが確保できないような状況ではプログラムが予想通りの動作をすることは期待できないから、
無駄なあがきをしてデータをぶっ壊すよりも、一度プロセスを落っことして、再起動したプロセスでリカバリするほうがよいとか何とか。
（記憶違いだったらごめんなさい）
なので、アプリが落ちるのは一見みっともないけど、実はそんなに悪くもない対応らしい。
#でもOSがクラッシュするのはあかんな。
Re: (スコア:0)
新人のころ、出力に信頼が求められる類のアプリで変に生かすよりも落とした方がいいって教育された思い出
Re: (スコア:0)
gzipのLZH脆弱性に対するパッチ [mie-u.ac.jp]は、明らかに入力がおかしくてまともに展開できるはずがないのに無理やり処理を続けるような方針でなかなかひどかった。あげくの果てに(micco氏が指摘する通り)パッチがバグってたし。Googleの研究者が書いたというのだからなかなか絶望感がある。ほかのLHA絡みのプロジェクトもたいていはほぼそのままこのパッチを取り込んでるし。
Re: (スコア:0)
よく言われるこれですね。
> Rule of Repair
> Developers should design programs that fail in a manner that is easy to localize and diagnose or in other words “fail noisily”. This rule aims to prevent incorrect output from a program from becoming an input and corrupting the output of other code undetected.