バグなどの早期発見についてのメモ

  • (by K, 2013.07.12)

(0) はじめに

  • 僕はpage0009の(3)と(4)で、不正なパラメータが渡されたときには、それをちゃんと検出できなければいけないと書いた。そうでないと、ライブラリがライブラリを呼び出すような状況の時に、バグを含んだパラメータがそのままどんどん伝播してしまい、デバッグを困難にしてしまう。
  • となると、不正なデータが来たらエラーとして止まってしまえばいい、だけじゃだめだ。不正なデータかどうかをチェックするサービスがそれぞれのライブラリに必要だ。これはいくつかのパラメータについては、より下位のモジュールでないと原理的に正当性が判定できないため。
    • たとえばハンドルを受け取っても、そのハンドルが正当なものかどうかは、ハンドルを発行したものにしか判断できない。
  • OSECPUにおいては「おかしなパラメータで呼び出しているのにそれを指摘できなければ、それは呼び出されたライブラリの脆弱性」である。

(1) メモ

  • 現在の最大の悩みは、呼び出し元の限定だ。僕は最初、リターンアドレスから呼び出し元を特定できると考えていた。しかしリターンアドレスを詐称するのは不可能じゃない。
    • つまりただのバグなら発見は容易だけど、悪意あるプログラムが、他人に罪をなすりつけたい場合を防げない。
  • 呼び出し元が確実に記録される関数呼び出し命令を作って、それ以外の呼び出し方法は受け付けないという関数の書き方を提供すればいいだろうか。
    • これを実現するには・・・
      • ポインタの属性を増やす必要がある(分岐元のモジュールIDの記録の強要)
    • というかこれに限らず、セキュアなモードではPCP命令はすべて分岐元を記録したらいいのも。それなら命令も増やさなくていいし、新属性もいらない。
      • debugInfo2かな・・・。
    • この分岐元情報を適当なハンドルにセーブさせて、「エラー源はこいつです」と言うための命令も用意する。
      • ハンドルのtyp値は0x80000000にしよう。
  • これが仮にできたとして、そうすると悪意あるプログラムにできる「不正」は以下だけになる。
    • 悪くない呼び出し元を、わざと「悪い」といって騒ぎ立てる。
  • となれば、エラーが起きた場合、エラーを起こしたプログラムと、「こいつが犯人ですぜ」と名指しされたモジュールの両方が同じくらいに疑わしい。


  • 命令コード 35 (3バイト命令)
    • 35 00 Pxx : debugInfo2をPxxに格納
    • 35 01 Pxx : セキュリティエラー検出(P3Fを指定すれば自身が原因or原因特定失敗)
    • 35 02 imm : セキュリティレベルに応じて、JITコンパイルを抑制

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2016-07-20 (水) 21:11:12 (911d)