ruby-dev

前田です。

Tanaka Akira wrote:
>>それでは、逆に安全だと判断したケース(たとえばschemeがhttpでGET/HEADのみ)
>>だけuntaintするようにすればよいのではないでしょうか。
> 
> 
> なぜ「schemeがhttpでGET/HEADのみ」というのを安全と判断するのでしょう?
> 
> 前田さんが [ruby-dev:26484] で示唆したように、その場合でも情報漏洩の危
> 険性はありますよね。 

たしかにそうですね。
「安全だと判断したケース」というのは適切ではありませんでした。
ユーザがそういう条件でredirectが起きることを理解して使うかぎりにおいて
安全ということなので、話が逆ですね。

> たとえば、perlsec の最初のほうに
> 
>        You may not use data derived from outside your program to affect some-
>        thing else outside your program--at least, not by accident.
> 
> という記述で始まるパラグラフがあります。これは perl の taint 機構が何
> を禁止するかという方針を (未定義な安全性とか危険性という言葉を使わずに) 
> 表現しています。たとえば、read mode な open はファイル名が taint であっ
> ても許されるというのはこの説明から理解できます。また、perl は秘密情報
> を読み込むことは禁止しておらず、taint 機構が有効だからといって情報漏洩
> はとくに防がれないということもわかります。
> 
> それに対して、Ruby の taint 機構には (少なくとも私は) そのような明示的
> な説明を見た覚えがありません。マニュアルには
(snip)
> しかたがないので、危険な操作のリストから ruby の方針を推測すると、read
> mode の open とか 1.9 で ENV[] が禁止されているところからみて、ruby で
> は秘密情報を内部に取り込むことによる情報漏洩の可能性も危険性として考え
> ているのではないだろうかと感じられます。

私もそう感じます。
perlsecの表現にならうと、現在のRubyのtaint機構の原則は、

  You may not use data derived from outside your program to access some-
  thing else outside your program--at least, not by accident.

という形で表現できるのではないかと思います。

> そうすると、open-uri で redirect を行うというのは、秘密情報を取り込ん
> でしまう可能性を生むわけですから、禁止するのは妥当かもしれないとも思う
> わけです。

デフォルトで禁止すること自体は妥当かもしれません。
ただ、たとえばfilename.tainted?がtrueだとしても
File.read(filename.dup.untaint)とすることができるわけですが、
現状のopen-uriでは(ユーザがライブラリ内部で取得されたデータをuntaint
することはできないため)そのように強制的に処理を行わせることができない
の点には不便さを感じます。
先の例のようにredirect先のURIを含む例外を発生させるとか、open時の
フラグか何かでredirectを強制させることができるようにするとかいった
処置はあった方がよいのではないでしょうか。

GET/HEADの場合に自動的にredirectをするというのは割と自然な挙動
(なのでプログラマもそれを期待したプログラムを書く)と思うので、
個人的には(ユーザが最初にopen-uriに渡したURIをuntaint
したことをもって)、redirectを許可してもよいのではないかなという
気もします。
File.open(filename)でfilenameがsymlinkだった時と似てますね。
# やっぱり、open-uriについても、デフォルトがどちらであれ、
# O_NOFOLLOWみたいなフラグがあった方がいいような気がします。


あと、taint機構が保護すべき操作の定義も問題なのですが、ライブラリ
が内部で取得したデータをどのように扱うべきかも問題な気がします。
「汚染されたデータによって外部の資源にアクセスできない」という原則を
そのままライブラリにも適用すると、今回のように動かないケースが出て
来ますよね。Cで書いてあるコードや、File.openのようにシステムコールの
中で外部からの入力を受け取っているケースなども考えると、(厳密に原則
を適用しようとすれば)問題となるようなケースはもっと多いかもしれません。

ライブラリに関しては、割り切って、

(1) 外部の資源にアクセスするメソッドについては、引数がtainted?ならば
    例外を発生させる(明示的に発生させなくても他のメソッドの呼びだしで
    発生すればOK)。
(2) 引数がtainted?でなければ、内部で取得したデータは必要に応じて勝手に
    untaintしてもよい。

という方針でもいいのかなとも思うのですが、乱暴すぎるでしょうか。

-- 
前田 修吾

Thread

Prev Next

In This Thread

Prev Next