複数のOSやハイパーバイザで脆弱性、CPUの予期しない挙動に対する解釈を誤ったのが原因? 21
ストーリー by hylom
CPUのドキュメントは難しい 部門より
CPUのドキュメントは難しい 部門より
複数のOSやスーパーバイザで、IntelおよびAMDのx86系プロセッサが備えるデバッグ例外処理を適切に処理していないという問題が発見された。これを悪用することでプログラムから本来アクセスできないメモリ領域にアクセスしたり、本来は実行する権限の無い操作を実行できる可能性があるようだ(ZDNet Japan、JVNVU#98401336、VU#631579)。
MOV SSおよびPOS SS命令の実行時にデバッグ例外が発生し、かつMOV SSやPOS SS命令の後に実行される命令が3より高い特権レベルの処理に制御を移すものだった場合に、デバック例外が3より高い特権レベルで実行されるという。その結果、MOV SSやPOS SS命令が予期しない振る舞いを起こす可能性があるという。
そして、複数のOSでこのような予期しない振る舞いが考慮されていないという。これは、ドキュメントやこれらの命令の使い方に対する説明が不明瞭であることが理由だと推測されている。
これはIntelのドキュメントが悪い (スコア:4, 興味深い)
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のマニュアルがミスリードしていた,マニュアルがよろしく無かった,と言われても仕方ない体裁かなと思います.(そしてこれを発見&報告した人はすごい人だと思います)
Re: (スコア:0)
とはいえ、Intelだけが悪いかというとそうでもなく、大抵の高機能なCPU/マイコンのドキュメントはこんなものです。
明文化されているだけマシで、メジャーではないものだとドキュメントにない仕様・不具合が山のようにあります。
おかしな挙動を指摘してあげると、忘れたころにドキュメントに追加されている。
一定期間でマニュアルを整理すればいいという意見もあるのですが、変更点を差分管理したいという要望もあり、難しいのでしょうね。
昔から (スコア:0)
ドキュメントに書いてない事や曖昧な所は叩いてみるのがアレゲ精神。
ドキュメントに書かれていても信用せずに叩いてみるのもアレゲ精神。
ドキュメントのせいでOSのほうの使い方がどうこうではなく、適当に叩いたぐらいで
セキュリティ機能をバイパス出来るようなCPUなのが悪いんじゃないの???
Re: (スコア:0)
WindowsもMacもLinuxもだっていうんだから、
現時点ではドキュメントも、CPUも悪いとしか思えないですね。
# なぜ、vmwareだけ逃れられたのか・・・
Re: (スコア:0)
vmwareではなく、ESXiでしたね。失礼。
Re: (スコア:0)
なぜってそりゃ読み間違えなかっただけだろう
Re: (スコア:0)
作り始めの時に割り込みベクタあたりから逆アセンブルして「よそと同じだからいいや」的に実装し、問題が起こらないからそのまま継承・・・ってのはありがちかも。
で時折こういう部分にこだわる人が担当するときっちり実装てのはありそう。
#そういうこだわる人は得てして「金にならん余計な仕事する」と批判が多かったりするけど
Re: (スコア:0)
おっと CVE-2012-0217 の悪口はそこまでだ
DOS 時代にデバッガ作っていた世代には既知の話だが (スコア:0)
仮想 386 モードでデバッガ作ったり使ったりしていた世代はまだ現役だと思うけど。
どこかで技術伝承に失敗したか。
まぁフラットメモリモデルに移行した時点で、セグメントレジスタ書き換えをすることが、まず無くなった。ってこと何だろうけど。
それとも、単一の(不完全な)ソースがあって、それを Windows / macOS / Linux でコピペしていた?
Re: (スコア:0)
VMのスーパーバイザなんて、元をたどればそれほど種類があるわけではあるまい。
x86系だと2系統か3系統しかなかろう。
特にMicrosoftは確実に外部から買ってきたものがベースだしな。
Re:DOS 時代にデバッガ作っていた世代には既知の話だが (スコア:1)
innotekとかConnectixが2006年前後に作りこんだ不具合が波及しているんじゃないか?
たぶんVMwareは別系統で同じミスをしたと推測できる。
Re: (スコア:0)
スタックの設定は、セグメントレジスタSSとスタックポインタESPへの設定の2命令が不可分なのですな
それでSSの設定だけが特別扱いされているのだが、存じなかったと
Re: (スコア:0)
DOS 時代はメモリ保護なんて気にしてないことがほとんどだから特権昇格とか気にしなさそうだけど、
仮想86モードで16bitコードを実行しているのにデバッグ割り込みで意図せず32bit実行モードに移っちゃうとかがあるのかな?
だとしたらそれはツライ。ソースコードに注釈いれて赤線ひいときたい。
# 仮想386 って何ぞやって思ったけど、デバッガの文脈から DOSエクステンダじゃなく仮想86モニタの話かなー、と。
# 勘違いしてたら解説もらえるとうれしい
BSD族 (スコア:0)
WinMac主要LinuxFreeBSDがアウトの中OpenBSDとNetBSDがセーフなのは「ころしてでもセキュアにする」「極力ハードウェア依存しない」というポリシーの成果なのだろうか
Re:BSD族 (スコア:2, おもしろおかしい)
> ころしてでもセキュアにする
健康のためなら死んでもいい。的精神ですね。
Re: (スコア:0)
PC-UNIX系ではNetBSDが好きな自分としてはほっこりします
MINIX3はどうなんだろう?
昔読んだ話だが (スコア:0)
OSの開発者はCPUにはバグが多くて仕様書どおりには動かないことを知っているとか記憶がある
(だからこっそりマイクロコードで修正してるとか)
Re: (スコア:0)
熟練の開発者は社内ライブラリにはバグが多くて仕様書通りには動かないことを知っているとか記憶がある
(だからこっそりマイクロコードで修正したりしなかったり、しないほうが多いか?)
#言いたかっただけです
Re: (スコア:0)
gccのバク見つけたとか嬉しそうに書いてる奴いるけどそんなに珍しくもないよね。
ちょっと新しい機能をつつくと結構出てくる。
Re: (スコア:0)
命令セットのバグなんてめったにありません(そもそもバグがあったら客が作ったプログラムがまともに動かない)
バグが多いのはCPUコアの部分ではなくて、プロセッサ内蔵のペリフェラル関係の動作
かつて某有名メーカーの著名プロセッサ内蔵ペリフェラルのとある動作モードのバグが発売開始後数年たって発覚・マスク変更になったことがある
#何年もたってそのようやくその特殊な動作モードを使う客が出てきたからバグが見つかったというオチ
Re: (スコア:0)
CPUのステッピングごとに違うエラッタがあったりするのでOSのコードを見るとエラッタ対応というコメントのついた
コードが山盛り見つかりますよ