In article <1125728642.258688.8357.nullmailer / x31.priv.netlab.jp>,
  Yukihiro Matsumoto <matz / ruby-lang.org> writes:

> もうちょっと具体的にお願いできますか。たぶん私が勘違いして他
> のことを考えているのだと思います。「シェルのメタキャラクタが
> シェルで処理されるときの挙動」でtaintと関係があるモノがあり
> ましたっけ。

たとえば、perlsec の例にある
           system "echo $arg";         # Insecure
というのは taint で防げるといわれている危険性で、最近は OS Command
Injection とも呼ばれますが、この危険性に対する攻撃はメタキャラクタを使
用して行われるところに関係があります。

たとえば、$arg が "; rm -rf /" とかだと困るわけですが、ここでは ; とス
ペースがシェルが解釈するメタキャラクタです。

メタキャラクタというのは要するにエスケープしない限りシェルが word の要
素でないものとして解釈する文字です。そういう文字は、$arg が word にな
ることを意図している場合には意図せざる影響を及ぼします。

では文字列に含まれている文字がすべてメタキャラクタでない、つまり word
の要素になる文字であれば危険はないかというと、そこで今回の空文字列につ
いて疑問が浮かびます。

$arg が空文字列でなかったとすれば、"echo $arg" で echo は引数をひとつ
受け取ります。それに対し、$arg が空文字列だったとすれば、echo は引数を
受け取りません。つまり、"echo $arg" において $arg が word になることを
意図していたとすれば、空文字列も意図せざる影響を及ぼすことになります。

この引数の有無の違いは、; でコマンドが二つに分かれるような変化に比べれ
ば軽微なものですが、それでもあまり自明でない挙動の変化をもたらすことが
あります。たとえば、人工的な例ではありますが、[ruby-dev:26907] であげ
た "grep #{pat} #{file}" では、pat が空文字列であるときに引数がひとつ
ずれ、file が grep の第一引数になって、標準入力から読むようになってし
まいます。

これらの変化はメタキャラクタも空文字列も単一の word という意図とは異な
る構造に解釈 (パーズ) されるという点で、類似性を感じます。

もし、空文字列に taint が伝播するのであれば、メタキャラクタを含む文字
列と同様に空文字列の問題も防げるのではないかと感じるのですが、空文字列
には taint が影響しないとすると、せっかく防げそうなのにもったいないなぁ、
と思うわけです。
-- 
[田中 哲][たなか あきら][Tanaka Akira]