パスワードを忘れた? アカウント作成
13595164 story
セキュリティ

複数のOSやハイパーバイザで脆弱性、CPUの予期しない挙動に対する解釈を誤ったのが原因? 37

ストーリー by hylom
CPUのドキュメントは難しい 部門より

複数のOSやスーパーバイザで、IntelおよびAMDのx86系プロセッサが備えるデバッグ例外処理を適切に処理していないという問題が発見された。これを悪用することでプログラムから本来アクセスできないメモリ領域にアクセスしたり、本来は実行する権限の無い操作を実行できる可能性があるようだ(ZDNet JapanJVNVU#98401336VU#631579)。

MOV SSおよびPOS SS命令の実行時にデバッグ例外が発生し、かつMOV SSやPOS SS命令の後に実行される命令が3より高い特権レベルの処理に制御を移すものだった場合に、デバック例外が3より高い特権レベルで実行されるという。その結果、MOV SSやPOS SS命令が予期しない振る舞いを起こす可能性があるという。

そして、複数のOSでこのような予期しない振る舞いが考慮されていないという。これは、ドキュメントやこれらの命令の使い方に対する説明が不明瞭であることが理由だと推測されている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • OSを作る人は Intel が公開しているCPUの仕様書,つまりドキュメントを読みます

    そのドキュメントはpdf形式で https://software.intel.com/en-us/articles/intel-sdm [intel.com] あたりでIntelが無料で公開しています.

    pdf は Vol.1 から始まり,Vol. 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, 4 と延々と続いていて,しかもそれぞれのpdfが数百ページあります.全体を通して読んで理解するのは大変な代物です.

    今回の脆弱性に関連する説明は Vol. 3A に記載されています.Vol.3Aは460ページあります.長いです.そして今回の脆弱性の原因となった挙動は
    - 72ページ目の割り込みフラグの話
    - 193ページ目のタスク切替時の割り込みマスク(スタックレジスタのアトミック処理)の話
    とに分断されて記載されていました.

    私は脆弱性のニュースを知って,それからマニュアルを眺めたのですぐに状況が把握できましたが,
    これはIntelのマニュアルがミスリードしていた,マニュアルがよろしく無かった,と言われても仕方ない体裁かなと思います.(そしてこれを発見&報告した人はすごい人だと思います)

    • by Anonymous Coward on 2018年05月12日 9時21分 (#3406942)

      かつての386システムプログラミングを知る人には基本的で重要なことで常識だったから
      (#3406645)や(#3406689)はすぐにピンときたのです
      というか昔の資料にはMOV SSとデバッグ例外の話はズバリ書いていたと思うが

      親コメント
    • by Anonymous Coward

      とはいえ、Intelだけが悪いかというとそうでもなく、大抵の高機能なCPU/マイコンのドキュメントはこんなものです。
      明文化されているだけマシで、メジャーではないものだとドキュメントにない仕様・不具合が山のようにあります。
      おかしな挙動を指摘してあげると、忘れたころにドキュメントに追加されている。
      一定期間でマニュアルを整理すればいいという意見もあるのですが、変更点を差分管理したいという要望もあり、難しいのでしょうね。

      • by Anonymous Coward on 2018年05月12日 0時35分 (#3406860)

        「こんなもん」が当たり前のようにまかり通ってるのに呆れ&ブチ切れケンカしたことある訳だが
        「ソフト屋はハード様の言うこと聞け」
        「ざけんなお前のとこのなんか使わんわ」
        「どうぞお好きに」
        だったね。日本のドコかまでは書かんが。
        で、アッチの方と直接やり取りしたらそうでもなくて会話が成立するのね。
        「すまぬそこ間違ってた」
        の返答あったとき、これは完全に負けてるなと痛感したわ。

        ハード+ソフトのトータルでどうするかが重要という考えが未だに無いのかと。

        親コメント
        • by Anonymous Coward

          それは国の問題ではなく、単に運が良かっただけでは?
          日常的にこういうやり取りしていますが、どこの国でも「それで、何個買ってくれるの?」が基準ですよ。

          購入ロットが小さければ、言葉が丁寧かどうかは別として対応してくれません。
          「すまぬそこ間違ってた」と言いつつ、直さないんですよね。
          大口の場合は、すぐにレポート作成してきたり、暫定マニュアルを作ってきたりします。
          開発費を出してる超大口でもなければ、バグの修正まで対応することはないですけどね。
          最近のプロセスだと1回修正回すだけで10億~なので、よほどのことでないと修正できない。

          • by Anonymous Coward

            #3406860は#3407031で関わった時の事でAPI作ってました。試験段階です。

            間違いは何であろうとあり得る、けど応対が真逆でしたね。
            まあ自分は抜けたのですが、Aの問題はAを直すべき(他の方法での回避は別の問題生む)の人なので大丈夫かと。

      • by Anonymous Coward

        ドキュメントの品質を超改善(単に正確であるだけでなく理解しやすく)しても中々金にならんからなあ。
        現実的には利用者が余分に金を出してでも品質を上げる価値はあるものなのだけど、
        商品としてのインパクトはやっぱり弱いのよね。

        • by Anonymous Coward on 2018年05月12日 12時32分 (#3407031)

          ある規格策定に携わった事がある方が、コードや仕様書全て通して正確&短く&シンプル&解釈ブレない表現のポリシー持ちでした。

          自分やった奴がそれだったので気に入ってくれたのですが「そういう考え持って実践してる人って珍しいね」でしたなあ。

          親コメント
        • by Anonymous Coward

          金にならんというか、ドキュメントの品質を保つのは一種の才能なんだよ
          時間が掛けてもダメなドキュメントしか書けないやつは書けない
          更に言うと、客先に出すドキュメントは一種の契約書で、正確であることが求められる
          誤解を招くような書き方するとそれはそれで揉めるんで
          簡易に考えると理解しやすくても複雑に書かざる得ない部分もある

          • by Anonymous Coward

            いや個人の才能に依存するのは金を掛けてない典型例でしょ。

            それ自体が儲かるプロジェクトなら人員と制作体制揃えて
            その為のシステムやツールも準備してユーザーのフィードバックにも応えていける。
            ドキュメントのクオリティを上げると利益が上がる計算なら当然投資した方が儲かる事になる。
            このてのドキュメントの大変更が掛けられないのはその編集人員と編集後のレビューやチェックにコストを割けない(割く価値がないと見なされてる)から。
            コストの問題がクリアできるなら詳細仕様と入門者向け概要を両方メンテする事だってできる。それが利益を生むのならね。

    • by Anonymous Coward

      数年ぶりにこのネタをかけるけど、Vmwareで仮想基盤環境を構築しその上にゲストOSを
      複数搭載し稼働させたさい、特にリソース不足でもないのに一つのゲストOSの挙動が
      きっかけでホストOSも一緒に停止すること稀にないですか?

      それはこのバグのせいです

  • by miyuri (33181) on 2018年05月12日 10時14分 (#3406958) 日記

    スタックがどうなっているのか、マッタクわからない。

  • by Anonymous Coward on 2018年05月11日 16時42分 (#3406641)

    これは、ドキュメントやこれらの命令の使い方に対する説明が不明瞭であることが理由だと推測されている。

    ドキュメントに書いてない事や曖昧な所は叩いてみるのがアレゲ精神。
    ドキュメントに書かれていても信用せずに叩いてみるのもアレゲ精神。

    ドキュメントのせいでOSのほうの使い方がどうこうではなく、適当に叩いたぐらいで
    セキュリティ機能をバイパス出来るようなCPUなのが悪いんじゃないの???

    • by Anonymous Coward

      WindowsもMacもLinuxもだっていうんだから、
      現時点ではドキュメントも、CPUも悪いとしか思えないですね。

      # なぜ、vmwareだけ逃れられたのか・・・

      • by Anonymous Coward

        vmwareではなく、ESXiでしたね。失礼。

      • by Anonymous Coward

        なぜってそりゃ読み間違えなかっただけだろう

      • by Anonymous Coward

        作り始めの時に割り込みベクタあたりから逆アセンブルして「よそと同じだからいいや」的に実装し、問題が起こらないからそのまま継承・・・ってのはありがちかも。

        で時折こういう部分にこだわる人が担当するときっちり実装てのはありそう。

        #そういうこだわる人は得てして「金にならん余計な仕事する」と批判が多かったりするけど

    • by Anonymous Coward

      おっと CVE-2012-0217 の悪口はそこまでだ

  • by Anonymous Coward on 2018年05月11日 16時47分 (#3406645)

    仮想 386 モードでデバッガ作ったり使ったりしていた世代はまだ現役だと思うけど。
    どこかで技術伝承に失敗したか。

    まぁフラットメモリモデルに移行した時点で、セグメントレジスタ書き換えをすることが、まず無くなった。ってこと何だろうけど。

    それとも、単一の(不完全な)ソースがあって、それを Windows / macOS / Linux でコピペしていた?

    • by Anonymous Coward

      VMのスーパーバイザなんて、元をたどればそれほど種類があるわけではあるまい。
      x86系だと2系統か3系統しかなかろう。
      特にMicrosoftは確実に外部から買ってきたものがベースだしな。

    • by Anonymous Coward

      スタックの設定は、セグメントレジスタSSとスタックポインタESPへの設定の2命令が不可分なのですな
      それでSSの設定だけが特別扱いされているのだが、存じなかったと

    • by Anonymous Coward

      DOS 時代はメモリ保護なんて気にしてないことがほとんどだから特権昇格とか気にしなさそうだけど、
      仮想86モードで16bitコードを実行しているのにデバッグ割り込みで意図せず32bit実行モードに移っちゃうとかがあるのかな?
      だとしたらそれはツライ。ソースコードに注釈いれて赤線ひいときたい。

      # 仮想386 って何ぞやって思ったけど、デバッガの文脈から DOSエクステンダじゃなく仮想86モニタの話かなー、と。
      # 勘違いしてたら解説もらえるとうれしい

  • by Anonymous Coward on 2018年05月11日 17時37分 (#3406683)

    WinMac主要LinuxFreeBSDがアウトの中OpenBSDとNetBSDがセーフなのは「ころしてでもセキュアにする」「極力ハードウェア依存しない」というポリシーの成果なのだろうか

    • Re:BSD族 (スコア:2, おもしろおかしい)

      by Anonymous Coward on 2018年05月11日 18時40分 (#3406717)

      > ころしてでもセキュアにする
       
      健康のためなら死んでもいい。的精神ですね。

      親コメント
      • by Anonymous Coward on 2018年05月12日 0時51分 (#3406862)

        不健康に生き永らえるくらいならむしろ死ぬ、はそれはそれで真っ当な思想のような気もする。

        親コメント
    • by Anonymous Coward

      PC-UNIX系ではNetBSDが好きな自分としてはほっこりします
      MINIX3はどうなんだろう?

  • by Anonymous Coward on 2018年05月11日 20時38分 (#3406767)

    OSの開発者はCPUにはバグが多くて仕様書どおりには動かないことを知っているとか記憶がある
    (だからこっそりマイクロコードで修正してるとか)

    • by Anonymous Coward on 2018年05月11日 21時49分 (#3406794)

      CPUのステッピングごとに違うエラッタがあったりするのでOSのコードを見るとエラッタ対応というコメントのついた
      コードが山盛り見つかりますよ

      親コメント
    • by Anonymous Coward

      熟練の開発者は社内ライブラリにはバグが多くて仕様書通りには動かないことを知っているとか記憶がある
      (だからこっそりマイクロコードで修正したりしなかったり、しないほうが多いか?)

      #言いたかっただけです

      • by Anonymous Coward on 2018年05月11日 21時53分 (#3406798)

        gccのバク見つけたとか嬉しそうに書いてる奴いるけどそんなに珍しくもないよね。
        ちょっと新しい機能をつつくと結構出てくる。

        親コメント
        • by Anonymous Coward

          GCCに夢を食われた人そんなに多いのか。

      • by Anonymous Coward

        ジャイアントコードで修正する必要がないだけマシだな
        大幅な変更で機能がうっかり変わったりするし

    • by Anonymous Coward

      命令セットのバグなんてめったにありません(そもそもバグがあったら客が作ったプログラムがまともに動かない)
      バグが多いのはCPUコアの部分ではなくて、プロセッサ内蔵のペリフェラル関係の動作
      かつて某有名メーカーの著名プロセッサ内蔵ペリフェラルのとある動作モードのバグが発売開始後数年たって発覚・マスク変更になったことがある
      #何年もたってそのようやくその特殊な動作モードを使う客が出てきたからバグが見つかったというオチ

    • by Anonymous Coward

      ん?
      本件は仕様書には一応書かれていたけどわかりにくかった、って話ですよね。

  • by Anonymous Coward on 2018年05月12日 10時40分 (#3406974)

    POS SSって違うんじゃね。

typodupeerror

Stay hungry, Stay foolish. -- Steven Paul Jobs

読み込み中...