perlsec - Perl のセキュリティ
Perlは、プログラムが setuid や setgid されるような特別な権限を付加されて 実行されたときでもセキュリティ保持が容易になるように設計されています。 スクリプトの一行ごとの多重置換を行うことに基づいているような大部分の コマンドラインシェルとは違って、Perl は隠れた障害が少ないような、 より便利な評価手法を用いています。 それに加えて Perl はより多くの組み込み関数を持っているので、 ある目的を達成するために(信頼できないかもしれないような) 外部プログラムを使うことが少なくてすむのです。
Perl のセキュリティ脆弱性を発見したと確信したときには、どうか詳細を perl5-security-report@perl.org にメールしてください。 これはクローズドで、アーカイブが残らないメーリングリストになっています。 Perl コアのセキュリティ問題についてだけこのアドレスを使って、独自に CPAN で配布されているモジュールについては使わないでください。
Perl は、そのプログラムが異なる実ユーザー ID、実効ユーザー ID、実グループ ID、 実効グループ ID を使って実行されることを検出したときに、 自動的に 汚染モード (taint mode) と呼ばれる特別なセキュリティチェックの セットを有効にします。 UNIX パーミッションにおける setuid ビットはモード 04000 で、 setgid ビットはモード 02000 です。 これらは重複してセットすることもできます。 汚染モードは、コマンドラインフラグ -T を使って陽に有効にすることもできます。 このフラグはサーバープログラムであるとか、 CGI スクリプトのような、他の誰かにすりかわって実行されるプログラムに 使うことを 強く 勧めます。
このモードで動作しているとき、Perl は明白な罠と隠れた罠の両方に対処するために 汚染検査 (taint check) と呼ばれる特別な警戒を行います。 これらのチェックの幾つかは、単純です。 path ディレクトリが他から書き込み可能でないことを検査するといったことがそうです。 注意深いプログラマーは常にこれらのことはチェックしています。 このほかのチェックはしかしながら、言語自身によって最も良くサポートされます。 そして、これらのチェックは特に set-id された Perl プログラムを 対応する C プログラムよりも安全にするのに貢献するのです。
自分のプログラムの外側から来たデータをプログラムの外の何かに影響を 及ぼすために使うことは、少なくともアクシデントででもなければ、できません。 すべてのコマンドライン引数、環境変数、ロケール情報(perllocale を参照)、 幾つかのシステムコールの結果(readdir(), readlink(), shmread() の変数、 msgrcv() が返したメッセージ、パスワード、getpwxxx() 呼び出しが返した gecos フィールドとシェルフィールド)、すべてのファイル入力といったものは “汚染された”(tainted) と目印が付けられます。 汚染されたデータは直接、間接を問わずサブシェルを起動するコマンドに使うことも、 ファイルやディレクトリ、プロセスに変更を加えるようなコマンドに 使うこともできません。 但し 以下の例外 があります。
print と syswrite の引数に対する汚染検査は 行われません。
シンボリックメソッド
$obj->$method(@args);とシンボリックサブルーチンリファレンス
&{$foo}(@args);
$foo->(@args);は汚染性がチェックされません。 これは、あなたの制御フローが外部データに影響されたいと思わないなら、 さらなる慎重さを要求します。 これらのシンボリックな値が何かを注意深く制限しないと、POSIX::system のような あなたの Perl コードの 外側 の関数を呼び出すことを可能にし、この場合 任意の外部コードを実行できるようになります。
ハッシュのキーは 決して 汚染されません。
効率上の理由から、Perl はデータが汚染されているかどうかについて保守的な 見方をします。 汚染されているデータが式に含まれている場合、たとえ副式の値自身は汚染された データに影響を受けない場合でも、全ての副式も汚染されたものとして 扱います。
汚染は各スカラ値に結び付けられるので、配列の幾つかの要素が汚染されていて、 そのほかの要素はそうではないということもありえます。 ハッシュのキーは 決して 汚染されません。
例を示します:
$arg = shift; # $arg は汚染された
$hid = $arg, 'bar'; # $hid も汚染された
$line = <>; # 汚染された
$line = <STDIN>; # これも汚染された
open FOO, "/home/me/bar" or die $!;
$line = <FOO>; # まだ汚染されている
$path = $ENV{'PATH'}; # 汚染されているが、下記を参照のこと
$data = 'abc'; # 汚染されていない
system "echo $arg"; # 安全ではない
system "/bin/echo", $arg; # 安全ではないと考えられる
# (Perl は /bin/echo について知らない)
system "echo $hid"; # 安全ではない
system "echo $data"; # PATHを設定するまでは安全ではない
$path = $ENV{'PATH'}; # $path が汚染された
$ENV{'PATH'} = '/bin:/usr/bin';
delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};
$path = $ENV{'PATH'}; # $path は汚染されていない
system "echo $data"; # これで安全!
open(FOO, "< $arg"); # OK - 読み込みのみのファイル
open(FOO, "> $arg"); # Not OK - 書き込みしようとしている
open(FOO,"echo $arg|"); # Not OK
open(FOO,"-|")
or exec 'echo', $arg; # Also not OK
$shout = `echo $arg`; # 安全でない。$shoutは汚染された。
unlink $data, $arg; # 安全でない
umask $arg; # 安全でない
exec "echo $arg"; # 安全でない
exec "echo", $arg; # 安全でない
exec "sh", '-c', $arg; # とても安全ではない!
@files = <*.c>; # 安全でない (readdir() のようなものを使う)
@files = glob('*.c'); # 安全でない (readdir() のようなものを使う)
# In Perl releases older than 5.6.0 the <*.c> and glob('*.c') would
# have used an external program to do the filename expansion; but in
# either case the result is tainted since the list of filenames comes
# from outside of the program.
$bad = ($arg, 23); # $bad は汚染されているかも
$arg, `true`; # 安全でない (実際はそうでなくても)安全でないことをやろうとすると、"Insecure dependency" や "Insecure $ENV{PATH}" のような致命的エラーとなるでしょう。
The exception to the principle of "one tainted value taints the whole expression" is with the ternary conditional operator ?:. 3 項条件を使ったコード
$result = $tainted_value ? "Untainted" : "Also untainted";というのは事実上
if ( $tainted_value ) {
$result = "Untainted";
} else {
$result = "Also untainted";
}なので、$result が汚染されたと考えるのは意味がありません。
ある変数が汚染されたデータを保持しているかどうかを検査するため、そして、 "Insecure dependency" メッセージの引き金になる可能性があるかどうかを 検査するために、CPAN にあり、5.8.0 からは Perl に含まれている Scalar::Util モジュールの tainted() 関数を使えます。 あるいは、以下のような関数 is_tainted() を使うことができます。
sub is_tainted {
return ! eval { eval("#" . substr(join("", @_), 0, 0)); 1 };
}この関数はある式のどこかにある汚染されたデータが式全体を汚染してしまうことを 利用しています。 これはすべての演算子に対して、そのすべての引数が汚染されているかどうかの 検査をするので効率は良くないでしょう。 その代わりに、一部の式において汚染された値にアクセスして式全体が 汚染されたとみなされるような場合には、もっと効率が良くて 保守的な方法が使われます。
しかし、汚染の検査は面倒です。 あなたのデータの汚染を取り除くだけということもあるでしょう。 値はハッシュのキーとして使うことで浄化されます; さもなければ、 汚染検査機構をバイパスするためのただ一つの方法は、 マッチした正規表現のサブパターンを参照することです。 Perl は、あなたが $1、$2 などを使って部分文字列を参照したときに、 あなたがパターンを記述したときに何を行うのかを知っていたと仮定します。 つまり、汚染されていないものを束縛しないか、機構全体を無効にするということです。 これは、変数がなんらかの悪い文字を持っているかどうかを 検査するというのではなく、変数が良い文字のみを持っていることの 検査には都合が良いです。 これは(あなたが考えもしないような)悪い文字を見失うことがあまりにも 簡単であるからです。
以下に示す例は、データに“語”(アルファベット、数字、アンダースコア)の 文字、ハイフン、アットマーク、ドット以外のものが入っていないことを 検査するものです。
if ($data =~ /^([-\@\w.]+)$/) {
$data = $1; # $data now untainted
} else {
die "Bad data in '$data'"; # log this somewhere
}これはかなり安全です。 なぜなら \w+ は通常シェルのメタ文字には マッチしませんし、ドットやダッシュなどのシェルにとって特別な意味を 持つようなものにもマッチしないからです。 /.+/ を使うのは、これはすべてを通してしまうのに Perl はそれを チェックしませんから、理論的には安全ではありません。 汚染を取り除くときには、自分のパターンについて十二分に注意せねばなりません。 正規表現を使ったデータの洗浄は、先に説明したより低い特権度の子プロセスを fork するための戦略を使うまでは汚れたデータの汚染除去 のみ の機構です。
先の例では、use locale が有効であるときには $data の 汚染除去を行いません。 なぜなら、\w にマッチする文字はロケールによって決定されるからです。 Perl は、ロケールで決まることを、それがプログラムの外から来たデータから 構成されているという理由によって信用できないものとみなします。 もしロケールを考慮したプログラムを書いていて、\w を含んだ正規表現で データの洗浄を行いたいというのなら、式の置かれたのと同じブロックの前の部分に no localeを置きます。 "SECURITY" in perllocale に詳しい説明と例があります。
自分の作ったスクリプトをコマンドのように使えるようにしたとき、システムは perl に対して、スクリプトの #! の行からコマンドラインスイッチを渡します。 Perl は、setuid(あるいは setgid) されたスクリプトに与えられた コマンドラインスイッチが #! 行にあるものと本当に一致するかどうかを検査します。 一部の UNIX や UNIX 風の環境では #! 行には一つのスイッチしか置けないので、 そういったシステムでは -w -U といった形式ではなく -wU のようにする必要があるでしょう(これは #! をサポートしていて、 setuid や setgid スクリプトが使える UNIX 環境や UNIX に似た環境でのみ 行なわれることです)。
汚染検査モード(-T) が有効のとき、"." ディレクトリは @INC から 取り除かれ、環境変数 PERL5LIB と PERLLIB は Perl から無視されます。 それでも、perlrun で説明されている -I コマンドラインオプションを 使うことで、プログラムの外部から @INC を調整出来ます。 二つの環境変数は不明確で、プログラムを実行している ユーザーはこの変数が設定されていることに気付かないかもしれないので 無視されますが、一方 -I オプションは明確に見えるので許可されます。
プログラムを修正することなく @INC を修正するもう一つの方法は、 lib プラグマを使うことです。つまり:
perl -Mlib=/foo program-I/foo ではなく -Mlib=/foo を使う利点は、後者だけが自動的に重複した ディレクトリを自動的に除去することです。
もし汚染された文字列が @INC に追加されると、以下の問題が報告されることに 注意してください:
Insecure dependency in require while running with -T switch"Insecure $ENV{PATH}" メッセージに対処するために、$ENV{'PATH'} に 既知の値を設定する必要があります。 そして path に含まれている各ディレクトリは、絶対パスで、 そのディレクトリの所有者やグループ以外からの書き込みを 禁じていなければなりません。 実行しようとしているファイルをフルパスで 書いたとしてもこのメッセージがでるので、びっくりすることがあるかもしれません。 このメッセージはプログラムのフルパスを書かなかったから出力されるではなく、 環境変数 PATH を設定しなかったり安全でない値を 設定したりしたために出力されるのです。 Perl は対象となっている実行ファイルが自分自身を方向転換したり、 PATH を参照して別のプログラムを起動したりするかどうかを知ることができないので、 確実に自分で PATH を設定するようにします。
この問題を引き起こす環境変数は PATH だけではありません。 一部のシェルでは、IFS、CDPATH、ENV、BASH_ENV のような環境変数を 使っていますから、Perl はこれらの変数がからであるかあるいは サブプロセスが起動したときに汚染されていないかどうかチェックします。 setid していたり、汚染検査をするスクリプトに 以下のような行を付け加えたくなるかしれません。
delete @ENV{qw(IFS CDPATH ENV BASH_ENV)}; # Make %ENV saferこのほかの、汚染された値を使っているかどうかに注意を払わないような 操作によってトラブルに巻込まれる可能性もあります。 ユーザーが使うようなファイル名を扱うファイル検査の使用を賢明なものにします。 可能であれば、ファイルをオープンした その後で 適切にスペシャルユーザー (グループも!)の特権を落とします。 Perl はあなたが読み出しのために汚染されたファイル名を使ってファイルを オープンすることを妨げませんから、出力の際には注意しましょう。 汚染検査機構はばかばかしいミスに対応するためのものであって、 必要なことを取り除くものではありません。
Perl は、system や exec に対してシェルのワイルドカードが あるかもしれないような文字列ではなく陽にパラメータリストを渡した場合には、 ワイルドカードの展開のためにシェルを呼び出したりしません。 残念なことに、open、glob、逆クォートといったものはそういった別の 呼び出し手順を提供していないので、より多くのごまかしが必要とされます。
Perl は、setuid や setgid されたプログラムから安全にファイルやパイプを オープンする方法を提供しています。 これは単に、汚れ仕事をするための制限された権利を持った子プロセスを 生成するというものです。 まず最初に、パイプによって親プロセスと子プロセスとを繋ぐ構文の 特別な open を使って子プロセスを fork します。 このとき、子プロセスはその ID セットをリセットしさらにその他の プロセス毎の属性をリセットして、オリジナルの、 もしくは安全な既知の値へと戻します。 それからもはや何の特別のパーミッションも持っていない子プロセスが open などのシステムコールを実行します。 ファイルやパイプは親プロセスよりも低い特権の元で実行されている 子プロセスでオープンされたので、すべきではないようなことを ごまかしておこなうことはできません。
以下に示すのは、安全に逆クォートを行う方法です。 どのようにして exec はシェルが展開するかもしれない文字列を伴って 呼び出されないようになっているかに注目してください。 これはシェルをエスケープする目的には最善の方法というわけではありません。 これは単に、シェルを呼び出さないというだけです。
use English '-no_match_vars';
die "Can't fork: $!" unless defined($pid = open(KID, "-|"));
if ($pid) { # parent
while (<KID>) {
# do something
}
close KID;
} else {
my @temp = ($EUID, $EGID);
my $orig_uid = $UID;
my $orig_gid = $GID;
$EUID = $UID;
$EGID = $GID;
# Drop privileges
$UID = $orig_uid;
$GID = $orig_gid;
# Make sure privs are really gone
($EUID, $EGID) = @temp;
die "Can't drop privileges"
unless $UID == $EUID && $GID eq $EGID;
$ENV{PATH} = "/bin:/usr/bin"; # Minimal PATH.
# Consider sanitizing the environment even more.
exec 'myprog', 'arg1', 'arg2'
or die "can't exec myprog: $!";
}readdir を代わりに使うことができるにしても、同様の戦略が glob を 通じたワイルドカードの展開でも有効です。
汚染検査は、農場をくれてやる (give away the farm) ためのプログラムを 記述することを自分自身に任せないということではなくて、 最終的にそれをつかって良からぬなにかを行おうとしているだれかを 信頼する必要がないというときに最も便利なものです。 これは、set-id プログラムや、CGI プログラムのように誰かに すり変わって起動されるようなプログラムに便利なセキュリティチェックです。
しかしながら、これは良からぬなにかを行おうはしないコードの作者を 信用しないということとは明らかに違います。 これは誰かが、プログラムをあなたが今まで見たことのないようにいじって 「ほら、これを実行して」と言わせるようなときに必要な種類の信用です。 この種の安全性のために、Perl の配布パッケージに標準で含まれている Safe モジュールをチェックしたほうがいいかもしれません。 このモジュールはプログラマーがすべてのシステム操作をトラップし、 名前空間のアクセスが注意深く制御されるような 特別な仕切り(compartment)をセットアップすることを許します。 しかし Safe は防弾であると考えるべきではありません: 無限ループ、 何ギガバイトものメモリ割り当て、ホストインタプリタをクラッシュや予測不能な 振る舞いをさせるための perl のバグの悪用をする外部コードすら防げません。 本当にセキュリティのことを考えるならどの場合も完全に防いだ方が良いです。
スクリプトと同じくらい柔軟に特別な権限をシステムに与えて しまう類の明白な問題の他に、多くの UNIX では、set-id されたスクリプトは 本質的に安全でない権利を最初から持っています。 その問題とは、カーネルにおける競合条件です。 インタープリターを実行するためにカーネルがファイルをオープンするのと、 (set-id された)インタープリターが起動してファイルを解釈するために 再度オープンするその間に、問題のファイルが変更されるかもしれません。 特に、使っているシステムがシンボリックリンクをサポートしている場合には。
幸運なことに、このカーネル“仕様”は使用禁止にできることもあります。 残念なことに禁止には二つのやり方があります。 システムは set-id ビットがセットされているスクリプトを単純に禁止することが できますが、このときはなにもできません。 もう一つ、スクリプトに付けられた set-id ビットを単純に 無視してしまうことができます。
しかし、kernel set-id スクリプト機能が禁止されていなければ、Perl は あなたの set-id スクリプトは安全ではないとやかましく主張することでしょう。 このとき、あなたは kernel set-id スクリプト機能を禁止するか、 スクリプトを C のラッパーで包んでしまうかのいずれかが必要です。 C ラッパーは、Perl プログラムを呼び出すことを除いては 何もしないプログラムです。 コンパイルされたプログラムは set-id されたスクリプトに関する カーネルのバグには影響されません。 次の例は、C で書いた単純なラッパーです:
#define REAL_PATH "/path/to/script"
main(ac, av)
char **av;
{
execv(REAL_PATH, av);
}このラッパーをコンパイルして実行ファイルにし、スクリプトではなく この実行ファイル を setuid したり setgid します。
近年、ベンダーはこのようなセキュリティバグに対する耐性を備えたシステムを 提供しはじめました。 そのようなシステムでは、インタープリターを起動するためにカーネルに set-id スクリプトが渡されたときにそのパス名をそのまま使うのではなく、 代わりに /dev/fd/3 を渡します。 これはスクリプトでは、あらかじめオープンされている特別なファイルですから、 邪悪なスクリプトをこじ入れるためにつかうことはできません。 こういったシステムにおいては、Perl は -DSETUID_SCRIPTS_ARE_SECURE_NOW を付加してコンパイルすべきでしょう。 Perl を構築する Configure プログラムは自分自身でこれを 見つけ出そうとするので、あなたが特別な何かをしなければならない、 ということはありあません。 SysVr4 の最近のリリースのほとんどや BSD4.4 は このアプローチをカーネルの競合条件を避けるために使っています。
ここで挙げるのは、あなたの Perl プログラムのソースコードをさまざまな “セキュリティ”のレベルで隠す方法です。
しかしまず最初にいっておきますが、ソースコードの読み込み権限を 落とすことは できません。 なぜなら、ソースコードは、コンパイルやインタープリットするために 読めるようになっていなければならないからです(これは、CGI スクリプトのソースが web の利用者から見ることができないというのとは違います)。 このため、パーミッションは 0755 レベルにしておかなければならないのです。 これによってあなたのローカルシステム上のユーザーはあなたのソースを 見ることだけになります。
一部の人達はこれをセキュリティ上の問題であると考えています。 あなたのプログラムが安全でないことを行っていて、 他人がそういったセキュリティの隙間をこじ開ける方法を知らないことに 頼っているのなら、それは安全ではないのです。 これはある人が安全でないことがらを見つけだし、 ソースを見ることなしにそれをこじ開けることの要因となります。 明快さを通したセキュリティはバグを直すのではなく隠すことに比べれば、 セキュリティをほんの少しだけしか傷つけません。
ソースフィルター(CPAN にある Filter::*, or Filter::Util::Call and Filter::Simple since Perl 5.8) を通して暗号化しようと することはできますが、クラッカーがそれを復号化することは可能でしょう。 先に説明したバイトコードコンパイラーとインタープリターを使うことも できますが、クラッカーはそれを逆コンパイルすることができるかもしれません。 ネイティブコードコンパイラーを使おうとしても、クラッカーはそれを 逆アセンブルできるかもしれません。 こういったことは、他人があなたの プログラムを手に入れようとすることを難しくしたりしますが、 プログラムを決定的に隠すことは誰にもできないのです(このことは、 Perl に限らずすべての言語にあてはまります)。
他人があなたのプログラムから受ける利益について気にしているのであれば、 制限つきライセンスがあなたに法的な安全を与えるでしょう。 あなたのソフトウェアのライセンスに、“本ソフトウェアは XYZ Corp.による、 公表されていない独占的ソフトウェアです。 あなたが使用するために これにアクセスすることは許可されておらず云々”のような脅し文句を 付けておきます。 あなたのライセンスの文言が法廷で確実に有効なものとなるように、 弁護士と相談したほうが良いでしょう。
Unicode は新しくて複雑な技術で、ある種のセキュリティの罠を簡単に 見落としてしまいます。 概要については perluniintro を、詳細については perlunicode を、 そして特にセキュリティ実装については "Security Implications of Unicode" in perlunicode を参照してください。
Perl の実装で使われているある種の内部アルゴリズムは、多くの時間や 空間を消費するように注意深く選択された入力によって攻撃可能です。 これにより サービス拒否(Denial of Service) (DoS) 攻撃と呼ばれている ものを引き起こすことができます。
ハッシュ関数 - ハッシュ要素を「並べる」ために使われるアルゴリズムは Perl の開発中に(主として高速化のために)数回変更されています。 Perl 5.8.1 ではセキュリティの側面も考慮されています。
5.8.1 以前の Perl では、ハッシュの内部構造が悪化するために Perl が 大量の時間を消費することになるようなハッシュキーとなるデータを かなり簡単に生成できました。 Perl 5.8.1 で、そのようなよくないハッシュキーを生成するのをより難しく するために、ハッシュ関数は擬似乱数の種によってランダムに攪拌されます。 さらなる情報については "PERL_HASH_SEED" in perlrun を参照してください。
Perl 5.8.1 ではランダムな攪拌はデフォルトで実行されていましたが、 5.8.2 からは内部が病的なデータの挿入を検出したときにのみ独立したハッシュに 使います。 もし何らかの理由で古い振る舞いをエミュレートしたい(そして DoS 攻撃に 我が身を晒したい)場合は、保護を無効にするために PERL_HASH_SEED 環境変数に 0 (あるいはランダムではなく既知の攪拌に強制したい場合はその他の任意の 整数) を設定できます。 古い振る舞いをエミュレートしたい理由の可能性の一つとしては、新しい 振る舞いでは、Perl を何回も実行するとハッシュキーの順序が毎回異なるので、 これによって混乱するアプリケーションがあるからです (例えば Data::Dumper: 2 回実行した結果はもはや同一になりません)。
Perl はハッシュキーの順序について何の保障もありません し、Perl 5 の 間でも既に何度か変更されています。 また、ハッシュキーの順序は、今までもこれからも、挿入順に影響を受けます。
また、ハッシュ要素の順序はランダム化されますが、この「擬似整列」は 以下のことに 使うべきではありません: リストをランダムに シャッフルするようなアプリケーション (Perl 5.8.0 から標準モジュールとなっている List::Util の List::Util::shuffle() や、CPAN モジュールである Algorithm::Numerical::Shuffle を使ってください)、 順列の生成 (CPAN モジュールである Algorithm::Permute や Algorithm::FastPermute を 使ってください)、あらゆる暗号アプリケーション。
正規表現 - Perl の正規表現エンジンは NFA (Non-deterministic Finite Automaton: 非決定性有限オートマトン)と呼ばれ、これは他のものに比べて、もし正規表現が 複数の方法でマッチングする場合、かなり簡単に大量の時間と空間を 消費することを意味します。 正規表現を注意深く構築することは助けになりますが、かなりの場合これは 不十分です ("Mastering Regular Expressions" という本を読む必要があります; perlfaq2 を参照してください)。 空間の不足は Perl がメモリ不足になることで明らかになります。
ソート - 5.8.0 以前の Perl で sort() 関数を実装するために使われていた クイックソートアルゴリズムは、大量の時間を消費するような策略がとても 簡単です。 Perl 5.8.0 から、異なったソートアルゴリズムであるマージソートが デフォルトで使われています。 マージソートは入力データによって影響を受けません。
さらなる情報については http://www.cs.rice.edu/~scrosby/hash/ および、 アルゴリズム的複雑性に関する情報工学の教科書を参照してください。
perlrun には環境変数を洗浄する方法が記述されています。