パスワードを忘れた? アカウント作成
13293590 story
バグ

Windows 7/8.1をWebページから停止させることも可能なNTFSのバグ 62

ストーリー by headless
停止 部門より
Windows 7/8.1のNTFSで、WebページからOSを停止させることの可能なバグが発見された(Ars Technicaの記事Aladdin RDのブログ記事The Vergeの記事)。

NTFSのマスターファイルテーブル(MFT)は、ルートディレクトリの「$mft」というファイルに格納されている。このファイルはファイルシステム上から参照することはできず、ファイル名を直接指定して開こうとしてもアクセスは拒否される。ただし、「C:\$mft\123」のようにディレクトリ名として指定してアクセスすると、新たにプログラムが起動できなくなったり、BSoDが発生したりする。

これはディレクトリとして$mftを開くために排他アクセスを取得し、ディレクトリでないことが判明した際に$mftのERESOURCEを解放してしまうことが原因となっているようだ。そのため、Windowsを再起動しない限り、Cドライブ上のファイルへのアクセスができなくなる。管理者権限は必要なく、標準ユーザーでも実行可能だ。Windows 7/8.1のほか、Windows Vistaにも影響するそうだ。Windows 10は影響を受けない。

実際に「start c:\$mft\123」や「dir c:\$mft\」といったコマンドをWindows 7/8.1のコマンドプロンプト上で実行してみたところ、システムの動作が次第に遅くなり、最終的にBSoDになる場合や、実行直後にBSoDになる場合、BSoDは発生しないものの何も実行できなくなり、強制的に電源を切るしかない場合など、さまざまな現象が発生した。

このようなパスをWebページで「img」タグに指定すると、リモートからシステムをクラッシュできるとのことで、Windows 9x時代のconcon攻撃にたとえられている。The Vergeでは実際に画像のソースに「C:\$mft\123」を指定したWebページを用意し、Windows 7上のInternet Explorerで開いてシステムの動作が遅くなることを確認したそうだ。Microsoftはこの件について知らされているが、Ars Technicaの記事掲載時点では修正の予定に関する回答はなかったとのことだ。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by BIWYFI (11941) on 2017年05月28日 13時49分 (#3218305) 日記

    うちは、歴史的経緯でWindowsをC以降のドライブに入れてる。
    //C:が満杯でWindowsを置けなかったのが最初の理由だったかな?
    以後、ドライブレターが変わるのが嫌いで、C:はダミーにし続けてる。

    アップグレードでドライブレターが変わらないことを利用したり、新規インストールでも、インストール時にダミーパーティションを作成すれば、C:以降のドライブにWindowsを置く事が出来た。(Win10でも出来る?)

    で、C:ドライブは、今はVHDをマウントしてる。
    Unix由来アプリのWindows版は、何故かC:に置く事が絶対になってたりするんで、容量可変のVHDはそれなりに便利。

    で、こう云う環境だと、C:ドライブは通常開かれてるパスに無い訳で、今回の被害も軽微になるんじゃないかと思う。
    実効の程は不明だが、選択肢の一つとして。

    --
    -- Buy It When You Found It --
    • by Anonymous Coward on 2017年05月28日 14時12分 (#3218316)

      うーん
      システムドライブである必要あるの?
      NTFSフォーマットされていれば対象なわけで
      システムドライブである必要があるんでしょうか

      システムドライブである必要があったとしても
      %SystemDrive%とか%HOMEDRIVE%とかで
      ドライブ番号不明でも$mftへ到達出来ちゃわないですかね

      対策としては
      Windows10移行へアップグレードして
      Adblock Plusやプロキシなどで排除登録するくらいでしょうか
      Adblock Plusでfile://登録できるが機能するかは試してないから知らんけど

      # パッチやアンチウイルスが対応する前にローカルファイル踏んじゃうようなドジっ子のことは知らん

      親コメント
      • by Anonymous Coward

        システムドライブでなければそのドライブは使えなくなるけど、クラッシュとかの致命的なことにはならないのでは? (そのドライブからシステムの動作に必要なファイルを読む必要がないから)

        > Adblock Plusやプロキシなどで排除登録するくらいでしょうか

        Adblock Plusが動くブラウザーなら最初から file:// へのアクセスは排除している

      • by Anonymous Coward

        >%SystemDrive%とか%HOMEDRIVE%とかで
        Webページから環境変数が参照できると思ってんのか

    • by Anonymous Coward

      うーん、自分ならそういう攻撃ページにはまずA~Zまで貼っとくかなあ…。

  • Windows 10 へアップグレードすれば済む話だもんね!

    • 今後どうなるかはわかりませんけども...

      Win10でも可能性はあるっぽい( http://qiita.com/yuna_priest/items/afe60c64cda6379860b6 [qiita.com] )
      ですね

      面倒なんで試してないので、実際の所は未確認です。

      なにかしらの方法で修正してほしいですが、どうなるやら。

      --
      M-FalconSky (暑いか寒い)
      親コメント
      • by Anonymous Coward on 2017年05月28日 13時53分 (#3218307)

        なんかリンク先のページ色々微妙…。

        > C:\$MFT\(適当な文字列) という風にアクセスすると、Windowsは$MFTがフォルダだと勘違いしてしまう。
        > これがそもそもの脆弱性だ。
        > すると、NTFSは$MFTが不安定になるのを防ぐために$MFTをロックしてしまう。

        うーんこの「素人向け」と称して色々端折って嘘を教えた(さもなければ教えている本人が本当にわかっていない)感

        > Win10 Pro 1516

        何その存在しないバージョン。

        > 例えば期限がある作業の途中だったとしよう。締め切り前とかね。
        > 貴方は「Photoshop」と「SAI」と「Clip Studio」をそれぞれ起動して夏コミの原稿描いている絵描きさんだとしよう。
        (中略)
        > もうお分かりだろう。今までの作業は全部パァだ。
        > 生産性の低下、作業戻りの発生という事態を招くことになる。
        > こうして人的リソースを容赦なく食い潰してくる、

        唐突なWindows 10ディスに草。

        えっ、違うの?

        親コメント
      • by Anonymous Coward

        すごいなこの記事。
        file://~の短縮URLがhttps://~に、って一体どういう事だ。
        プロトコル違うんだからそもそも短縮出来ないだろ……。
        そして、Windows 10では当然発生しない。検証した。

        しかもアホな妄想ですって認める事もなく

        > 何もこれは、エラーを起こすことが目的ではないのである。
        起きなかったら、「よかったね!ラッキーだよアンタ!何も心配せずにネットを楽しんでくれよな!」ということにしかならない。
        > 脆弱性やセキュリティホールの類は「問題が起きる可能性がある」と指摘することが大事だ。

    • by Anonymous Coward

      何でこんな美味しいネタをWindows 7/8.1のサポート終了までとっておかなかったのか。
      MSの反応の鈍さからしてMS17-010みたいに修正がサポート終了したOSまでバックポートされることはなさそうだし。

      • by Anonymous Coward

        いや、取っておいた人は(複数)いるんじゃないかな。逆セキュリティ業界では裏切り者が1人でも出たら全部パーだから。

        • by Anonymous Coward

          任意コード実行とかできるわけじゃないからそういう業界的に先走ることで得られる旨みも大してないと思うんだよなあ

          • by Anonymous Coward

            DOSの事ばっかりに話が行ってるけど、ファイルシステムに詳しい人なら別の使い道もあるんじゃないの?

  • by Anonymous Coward on 2017年05月28日 11時55分 (#3218275)

    いまだにこんな仕様が残っているというのは
    懐かしいような嬉しいような

    • by Anonymous Coward on 2017年05月28日 12時32分 (#3218283)

      懐かしの<img src="file:///c|/con/con/con">を思い出して、懐かしい気持ちになったのは俺だけじゃないはず
      むしろ、今まで何で発見されなかったのか不思議なレベルのバグだな

      親コメント
      • by Anonymous Coward

        そもそもhttp(s):のページからのfile:へのリンクなんてとっくに無効にされているものだと思ってたけど、
        いまだに許されているということは、真っ当な用途で使ってる人もいるのか?

        • by Anonymous Coward

          ヒント: いまだに許されているのはIEだけ

  • by Anonymous Coward on 2017年05月28日 13時43分 (#3218300)

    今回のような脆弱性でなくても、Webページ作成のときにローカルファイルを読み込んだものが修正されなかったのかなんなのか、file://..が残ったままのページがときどきあるんです。サーバ名が指定されていることもあって、そういうページを読み込むとWindowsファイル共有と解釈してしまうのかアクセスに行くらしいです。

    file://なんて解釈する必要あるんでしょうか。イントラネットゾーンとか以外では基本無視でいいんじゃないですか?

    • by Anonymous Coward on 2017年05月28日 23時00分 (#3218522)

      「ちょっとFirefoxでfile:///proc/cpuinfo [proccpuinfo]開いてみて?
      で、model nameの行をコピペしてくれる?」

      というのが、Linux系OSではできる。

      でも、Kubuntuで試す限り、Firefoxでは通るけど
      Google Chromeでは、少なくともデフォではfile:///は通らないみたい

      親コメント
    • by Anonymous Coward

      ローカルのhtmlファイル+画像が読めないと困る
      困らない?

      • by Anonymous Coward

        (file:)ローカルのページからローカルのファイルが開けるのは便利だけど
        リモート(http:)のページからローカルのファイルが開けるのは危険以外ないだろう。

        昔はボケてそれやってるサイトとか結構あって画像は表示されないし
        勝手にHDDにアクセスに行くしで困ったもんだよ。

        まさか今でもその穴が塞がってないのか?

        • by Anonymous Coward

          気になって試してみたけどさすがに無いね(Win10)。
          img src="file:///C:/img.png" 表示されたらどうしようと思ったわ。
          ちなみにChromeはコンソールに Not allowed to load local resource: を吐くけど、IE(11)/Firefox/Edgeはガン無視。

          で、7ではローカルファイルへのアクセスが起きるのか?よくわからんな。

      • by Anonymous Coward

        まさかwebブラウザでローカルファイルが開けないと困るとかいう話だと勘違いしてる?

  • by Anonymous Coward on 2017年05月28日 13時46分 (#3218303)

    > このようなパスをWebページで「img」タグに指定すると、リモートからシステムをクラッシュできる

    リモートのWebページ上でローカルPC上のリソースを使えなんて記載しても
    イマドキのブラウザのデフォルトなら門前払いじゃ?

    ローカルコンテンツの表示をわざわざ許可するようセキュリティレベルを利用者が下げてるとか、
    HTMLリソースをダウンロードしたあとローカルで開く場合にしても
    「インターネットから取得されたファイルに対して自動設定される制限」を
    手動で制限解除してる必要がある気がする

    • by Anonymous Coward

      ですよね。デモを見て騒いでる人は最初からセキュリティを利用者側で下げてるとしか言えない。ネットって自己責任なんだよ

    • by Anonymous Coward

      ダウンロードしたファイルに対するアクティブコンテンツの制限も、画像の読み込みには及ばないから無意味。
      ていうかイマドキのブラウザじゃないIEはデフォルトの設定で読み込むからダウンロードさせる必要すらないし。

  • by Anonymous Coward on 2017年05月28日 15時01分 (#3218334)

    リモートのウィンドウズマシンのc:\へのアクセスが可能になればこの脆弱性をつける。

    • by Anonymous Coward

      鍵のかかったドア、鍵を持ってないあなた。
      「ドアの開け方がわかったぞ! 鍵を持ってくればいい!」
      さて、意味はある?

      • by Anonymous Coward

        これに限らず多くの脆弱性は単体では使いみちのないものだよ。他の脆弱性と組み合わせないと使いみちがない。

  • by Anonymous Coward on 2017年05月28日 18時06分 (#3218420)

    Vista、XP、2000、NT4.0は大丈夫なのかな?

    • by Anonymous Coward

      試してはいないけど書かれてる内容的に2000以降でNTFS使ってれば
      間違えなく共通の問題だろうね

  • by Anonymous Coward on 2017年05月29日 0時45分 (#3218542)

    互換性のためにMBRがあるから駄目かな?
    windowsカーネルの結構深いところの問題の気がするから修正は難しそう

    • by Anonymous Coward

      MBR は関係ないと思うが

typodupeerror

192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり

読み込み中...