パスワードを忘れた? アカウント作成
13729148 story
Firefox

非常に長い名前のBlobでFirefoxをクラッシュさせる攻撃 29

ストーリー by hylom
新バグ 部門より
headless曰く、

CSSを使用してSafariをDoS攻撃する実証コードが先日話題になったが、作者のSabri Haddouche氏(pwnsdx)が今度はJavaScriptを使用してFirefoxをDoS攻撃する実証コードを公開している(Bleeping ComputerBetaNewsNeowin)。

この攻撃は非常に長い名前のBlobを生成して繰り返しダウンロードさせることでFirefoxがクラッシュするというもの。条件によってはOSがクラッシュすることもあるという。実証コードはGitHubで公開されているほか、Webサイト「Browser Reaper」で実際に動作を試すことも可能だ。Windows 10上のFirefox 62で試してみたところ、メモリ使用率が大きく増加していき、Windows自体の操作も困難になった。長い時間はかかったものの何とかPCをスリープさせることができ、復帰後にFirefoxのみクラッシュしたが、放置すればWindowsごとクラッシュするかもしれない。なお、Bleeping Computerの記事ではモバイル版のFirefoxには影響しないとしているが、Android版Firefoxで実行して放置するとアプリがクラッシュした。

この攻撃は以前話題になったGoogle Chromeに対する攻撃と似ている。ChromeのデフォルトではWebサイトによる複数ファイルの連続ダウンロードにユーザーの許可が必要になるため、許可を求めるダイアログで「ブロック」をクリックすれば攻撃を回避できる。ただし、Chrome 69ではダイアログが出たまま放置するとフリーズした。Windowsの応答も遅くなったが、タスクマネージャーでChromeを終了させることは可能だった。Microsoft Edgeの場合はダウンロード確認の通知が表示され、一時的にメモリ使用率が増加するものの、しばらくするとページがリロードされて元の状態に戻った。

MozillaのBugzillaでは複数ファイルの自動連続ダウンロードに対する保護の必要性が2年前から議論されている。ただし、今回の実証コードに対するバグリポート(報告者はおそらくHaddouche氏)は複数ファイルのダウンロードではなく、Blob URLの扱いに関するバグ1438214に統合された。バグ1438214は2月から議論されているが、こちらも現在のところ有効な解決策は出ていないようだ。

Browser ReaperではSafariに対するDoS攻撃の実証コード(Reap Safari)と今回の実証コード(Reap Firefox)に加え、Chromeに対するDoS攻撃の実証コード(Reap Chrome)を試すこともできる。こちらは履歴のナビゲーションをループさせる攻撃だ。Chromeでは実行後しばらくするとタブがクラッシュし、Edgeではページがリロードされた。一方、Firefox上ではReap Firefoxの実行時と同様の状態になってしまった。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • これ、症状の記述だけから見て取れるのは、メモリ使用量を膨らませる攻撃なんだよね。
    遅くなる話はメモリ使用量増加によるスラッシングだろうし、クラッシュはメモリもswap(=ディスクの空き)も使い切って次のメモリ確保に失敗したからだよね。

    リークじゃなくて、ダウンロードが全部完了するまでメモリ開放しないからってことかな?

    • by Anonymous Coward

      実際に動かしてみたら、保存先の確認が出て、どうしようかなーと思っている10秒ぐらいでブラウザがクラッシュした。
      複数ダウンロードの許可を求めてきたけど、許可も拒否もしないのに先のプロセスに進んでしまったので意味をなさないっぽい。
      実証コードは生成したBlobを猛烈な勢いで保存しようとしているだけ。悪意がなくてもバグでやらかしそうな感じのコードだなこれ。

      • どうせ二択なんだからボタンが押されるのを待っている間にもある程度ダウンロードしておけば結果的に待ち時間が短くなる。キャンセル押されたらメモリ内にダウンロードした内容を破棄すればいいだけ。デメリットは無駄なトラフィックを生んだことくらい。
        巨大なデータをダウンロードすることは十分考えられるので、たぶん先読みサイズの上限みたいなものは設定されてると思われる。

        確認ダイアログに表示するためにファイル名を取得する必要がある。
        「非常に長いファイル名×膨大な応答待ちダイアログ」という形でダウンロード待ちが増えることによって、データ自体はダウンロードしてなくても大量にメモリを消費させることができる。
        つまりダイアログにファイル名を表示していれば、先読みをやめても何の解決にもならないかも。

        --
        うじゃうじゃ
        親コメント
  • by Anonymous Coward on 2018年09月28日 8時06分 (#3488183)

    非常に長い名前のBlobを読み込まない様にすれば良いだけなのでは・・・

    • by Anonymous Coward

      今から1億文字の長さの名前のデータ送るんでよろしく!

    • by Anonymous Coward

      非常に長いと言っても27KBぐらいですからねえ。

      • by Anonymous Coward

        長いでしょ。
        Windowsじゃ260文字までしか使えないのだから

      • by Anonymous Coward

        手元ところで確認したら9128000バイト≒8.7MBだったんだけど、その数値はどこから?

        • by Anonymous Coward

          ごめんなさい、コード斜め読みでrepeat()は処理繰り返してる部分かなとか思ってた。27KBは生成元の文字列(というかソースコードのファイルサイズ)。
          8MBだとちょっと大きいね。

  • by Anonymous Coward on 2018年09月28日 9時14分 (#3488208)

    氏名:じゅげむじゅげむごこうのすりきれかいじゃりすいぎょのうんらいまつふうらいまつ・・・あと忘れた

    • by Anonymous Coward

      ここに記すには余白が狭すぎる。

    • by Anonymous Coward

      一応、残りは以下の通り...

      くうねるところにすむところ
      やぶらこうじのぶらこうじ
      ぱいぽぱいぽぱいぽのしゅーりんがん
      しゅーりんがんのぐーりんだい
      ぐーりんだいのぽんぽこぴーの
      ぽんぽこなーの
      ちょうきゅうめいのちょうすけ

      • by Anonymous Coward

        最初に聞いたバージョンだと

        五劫の擦り切れズ、だったんだよね

        「五劫の擦り切れ」より永いとか言ってた。アドリブだったのかな

        • by Anonymous Coward

          「五劫」経過後も擦り切れない=事実上不滅ってことで,漢文的にいうと「不レ擦切」なんじゃ?
          逆に「擦り切れ」だと五劫でなくなっちゃってるような印象

  • by Anonymous Coward on 2018年09月28日 11時41分 (#3488286)

    普通に開発していても、間違って変なコード書いてしまうとハングしてにっちもさっちもいかなくなることって結構あると思うが。

    • by Anonymous Coward

      ブラウザがDoSになるのはしょうがないとしても、OS巻き込んでるのは良くないね。というか、そろそろOSはCPUとメモリをUI側に取っておく工夫がいるんじゃないかな。

      • by Anonymous Coward

        ブラウザがDoSになるのはしょうがないとしても、OS巻き込んでるのは良くないね。というか、そろそろOSはCPUとメモリをUI側に取っておく工夫がいるんじゃないかな。

        ブラウザがDOSでOS巻き込むならメモリは640kbでじゅうぶんですよ!(違

        • by Anonymous Coward

          もうそうなると、(物理)メモリで無く、仮想記憶(ページファイル)が阿鼻叫喚なのでは?
          アプリのプロセスはすべてゼロテスターで、System(PID=4)だけ鬼の様に動いている
          状況では?

    • by Anonymous Coward

      趣味で書いてたスクリプトが、AndroidのChromeを確実に強制終了させるようになっちゃったことがある。このストーリーと同じく大量のデータをダウンロードするようなスクリプトだったけど。

      で、Chromeは、「最後に開けていたページのURL」を覚えてから死んだようで、次に起動すると、前回異常終了したのでなるべく元通りに復帰しようとして、そのページを開けて落ちる、と言う状態でハマった。

      単発で落ちるだけならまだしもだけど、もう2度とChromeを使えない状態に陥るのはソフトウェアとしてダメだと思う。

      ウェブページの方を消してから再起動で、死のループを断ち切れたけど、そうじゃなかったら、データ・キャッシュのクリアとかが居るのかも知れない。あるいはセーフモードで起動、的な方法も用意されてたりするのかな?

    • by Anonymous Coward

      少なくともMSは任意コード実行につながらないような単なるDoSはセキュリティパッチを提供する必要のある脆弱性とは認めていないね(ただし普通にその後修正されることはある)。

  • by Anonymous Coward on 2018年09月28日 12時44分 (#3488321)

    もう、buffer overflow is error でいいんじゃないかとつくづく。
    なんのためのC/C++ なのか。

  • by Anonymous Coward on 2018年09月28日 14時04分 (#3488364)

    何か潜んでるとしか思えない

  • by Anonymous Coward on 2018年09月28日 16時21分 (#3488464)

    たとえ64bitアプリでも、標準でメモリ最大1Gとか2Gとか4Gとかしかつかわないようにして、
    それを超えたらOSがプロセス強制停止するようにすればいいとおもう
    作成するファイルの最大サイズにも標準で制限加えるとかね
    もちろん、本当にメモリが必要なアプリは、コンパイルオプションでリミッターはずすことも可能とか

    • by Anonymous Coward

      ほとんどの64bitアプリがリミッターはずしてコンパイルされることになるだけでは。

      • by Anonymous Coward

        普通の OS なら、前世紀からメモリ最大量とかディスク使用量とか、OS 側から制限できるよ。
        # Windows の事は知らないけど、最近のであれば出来ないわけがないよね。

        • by Anonymous Coward

          普通のOSがどんなものか知らんが、アプリ毎にディスク使用量を設定できるOSは知らんな。

          • by Anonymous Coward

            Quotaとか、結構昔からあるありふれた機能なんだけどね。
            Windowsだってやろうと思えば出来るよ、ただやろうとしないだけでね。

          • by Anonymous Coward

            アプリ毎に異なるUIDを振る。
            初期状態の /etc/passwd にもその手のエントリが入ってるでしょ。

    • by Anonymous Coward

      一度メモリ不足が発生すると、リカバリしようとしてもその処理を行うためのメモリが取得できる可能性が危ういから、
      大人しくクラッシュさせてしまうのが定石。それでもよければ。

      でも、最近はChromeみたいにプロセス大量に作る奴が多いし、子機能は別のexeを持ってたり、
      vbsだのpowershellだの共用のエンジン使う奴はどーすんのとか、細かく設定定義するのは大変よ?

typodupeerror

日々是ハック也 -- あるハードコアバイナリアン

読み込み中...