perlsec - Perl のセキュリティ
Perlは、プログラムが setuid や setgid されるような特別な権限を付加されて 実行されたときでもセキュリティ保持が容易になるように設計されています。 スクリプトの一行ごとの多重置換を行うことに基づいているような大部分の コマンドラインシェルとは違って、Perl は隠れた障害が少ないような、 より便利な評価手法を用いています。 それに加えて Perl はより多くの組み込み関数を持っているので、 ある目的を達成するために(信頼できないかもしれないような) 外部プログラムを使うことが少なくてすむのです。
Perl インタプリタや、コア Perl コードベースで管理しているモジュールの セキュリティ脆弱性を発見したと確信したときには、詳細を perl-security@perl.org に メールしてください。 このアドレスは Perl セキュリティチームによって監視されている、 閉じられたメンバーのメーリングリストです。
追加の情報については perlsecpolicy を参照してください。
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() のようなものを使う)
# どちらの場合でも、glob の結果は汚染されています; ファイル名の一覧は
# プログラムの外部から来るからです。
$bad = ($arg, 23); # $bad は汚染されているかも
$arg, `true`; # 安全でない (実際はそうでなくても)安全でないことをやろうとすると、"Insecure dependency" や "Insecure $ENV{PATH}" のような致命的エラーとなるでしょう。
「一つの汚染された値が式全体を汚染する」の原則の例外は、3 項条件演算子 ?: です。 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 {
local $@; # Don't pollute caller's value.
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) が有効のとき、 環境変数 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 switch5.26 より前のバージョンの Perl では、汚染モードを有効にすると、 @INC のデフォルト値からカレントディレクトリ (".") を削除します。 バージョン 5.26 からは、デフォルトではカレントディレクトリは @INC に 含まれていません。
"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;
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 された)インタープリターが起動してファイルを解釈するために 再度オープンするその間に、問題のファイルが変更されるかもしれません; 特に、使っているシステムがシンボリックリンクをサポートしている場合には。
一部の Unix、特に最近のものは、このようなセキュリティバグに対する耐性を 備えています。 そのようなシステムでは、インタプリタを起動するためにカーネルに set-id スクリプトが渡されたときにそのパス名をそのまま使うのではなく、 代わりに /dev/fd/3 を渡します。 これはスクリプトでは、あらかじめオープンされている特別なファイルですから、 邪悪なスクリプトをこじ入れるためにつかうことはできません。 こういったシステムにおいては、Perl は -DSETUID_SCRIPTS_ARE_SECURE_NOW を付加してコンパイルすべきでしょう。 Perl を構築する Configure プログラムは自分自身でこれを 見つけ出そうとするので、あなたが特別な何かをしなければならない、 ということはありあません。 SysVr4 の最近のリリースのほとんどや BSD4.4 は このアプローチをカーネルの競合条件を避けるために使っています。
安全なバージョンの set-id スクリプトがない場合でも、他に手段が ないわけではありません。 カーネルは set-id スクリプトを set-id で実行しないか、 これらを全く実行しないことで、 このカーネル「仕様」は使用禁止にできることもあります。 どちらかの方法で競合条件の悪用可能性を避けることができますが、 実際にスクリプトを set-id で実行する助けにはなりません。
kernel set-id スクリプト機能が禁止されていなければ、 任意の set-id スクリプトは悪用可能な脆弱性を持ちます。 Perl は悪用可能性を避けることはできませんが、 可能性のある脆弱性のあるスクリプトを示すことはできます。 Perl が set-id スクリプトが適用されていることを検出した場合、 あなたの set-id スクリプトは安全ではないとやかましく主張し、 実行しません。 Perl が文句を言った場合、脆弱性を取り除くためにスクリプトから set-id ビットを取り除く必要があります。 スクリプトの実行を拒否することは、それ自体で脆弱性を閉じることはありません; これは単にそうするようにあなたを後押しする Perl の方法です。
実際に set-id でスクリプトを実行するために、安全なバージョンの set-id スクリプトを持っていない場合は、 スクリプトを C のラッパーで包む必要があります。 C ラッパーは、Perl プログラムを呼び出すことを除いては 何もしないプログラムです。 コンパイルされたプログラムは set-id されたスクリプトに関する カーネルのバグには影響されません。 次の例は、C で書いた単純なラッパーです:
#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>
#define REAL_PATH "/path/to/script"
int main(int argc, char **argv)
{
execv(REAL_PATH, argv);
fprintf(stderr, "%s: %s: %s\n",
argv[0], REAL_PATH, strerror(errno));
return 127;
}このラッパーをコンパイルして実行ファイルにし、スクリプトではなく この実行ファイル を setuid したり setgid します。 このラッパーは、スクリプトが使われる安全なパスであることを保証する以外に 実行環境をサニタイズしないことに注意してください。 これはシェバン競合条件のみを回避します。 スクリプトを set-id で実行するのに十分なぐらい安全であることは、 これは Perl 自身の機能と、スクリプト自身が注意深いことに依存しています。
ここで挙げるのは、あなたの 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 でこのような攻撃に対する Perl の強化が導入され、後に Perl 5.18.0 で これらの機能は拡張され、追加の防御が追加されました。
これを書いている時点では、Perl 5.18.0 はハッシュ実装に対するアルゴリズム的 複雑性攻撃に対してよく防御されていると考えられています。 これは主に以下のような要素が攻撃を緩和していることに依ります:
攻撃キー集合を生成するための種が何かを知ることを不可能にするために、この種は プロセス開始時にランダムに初期化されます。 これは PERL_HASH_SEED 環境変数を使うことで上書きできます; "PERL_HASH_SEED" in perlrun を参照してください。 この環境変数はアイテムが実際にどのように保管されるかを制御するもので、 keys, values, each 経由でどのように表現されるかを 制御するものではありません。
ハッシュ関数でどの種が使われるかとは独立に、keys, values, each は ハッシュ毎にランダム化された順序で要素を返します。 挿入によってハッシュが変更されると、そのハッシュの反復順が変わります。 この振る舞いは、Hash::Util の hash_traversal_mask() を使うか、 PERL_PERTURB_KEYS 環境変数を使うことで上書きできます; "PERL_PERTURB_KEYS" in perlrun を参照してください。 この機能は keys の「見える」順序を制御するもので、実際に保管される順序を 制御するものではありません。
あるハッシュバケツで要素が衝突したとき、Perl 5.18 ではチェーンに保管される順番は もはや予測できなくなりました。 これは、衝突を観測するのをより困難にする意図があります。 この振る舞いは PERL_PERTURB_KEYS 環境変数を使うことで上書きできます; "PERL_PERTURB_KEYS" in perlrun を参照してください。
デフォルトハッシュ関数は、ハッシュの種の推論をより難しくするために 修正されました。
ソースコードには選択できる複数のハッシュアルゴリズムが含まれています。 デフォルトの perl ハッシュは攻撃に頑強であると信じていますが、 フォールバックオプションとして Siphash ハッシュ関数も含めています。 Perl 5.18.0 のリリースの時点で、Siphash は暗号学的強度を持つと 信じられています。 これはデフォルトのハッシュよりもはるかに遅いので、デフォルトではありません。
特別な Perl をコンパイルしない限り、Perl 5.18.0 より前のバージョンと正確に 同じ振る舞いにする方法はありません。 最も近いのは、PERL_PERTURB_KEYS に 0 を設定し、PERL_HASH_SEED に既知の値を 設定することです。 上述のセキュリティ上の問題のため、製品にはこの設定をしないことを勧めます。
Perl はハッシュキーの順序について何の保障もありません し、Perl 5 の 間でも既に何度か変更されています。 また、ハッシュキーの順序は、今までもこれからも、挿入順と、ハッシュに対して 行われた変更の歴史の影響を受けます。
また、ハッシュ要素の順序はランダム化されますが、この「擬似整列」は 以下のことに 使うべきではありません: リストをランダムに シャッフルするようなアプリケーション (Perl 5.8.0 から標準モジュールと なっている List::Util の List::Util::shuffle() や、CPAN モジュールである Algorithm::Numerical::Shuffle を使ってください)、 順列の生成 (CPAN モジュールである Algorithm::Permute や Algorithm::FastPermute を 使ってください)、あらゆる暗号アプリケーション。
tie されたハッシュは独自の順序とアルゴリズム的複雑性攻撃があるかもしれません。
正規表現 - Perl の正規表現エンジンは NFA (Non-deterministic Finite Automaton: 非決定性有限オートマトン)と呼ばれ、これは他のものに比べて、もし正規表現が 複数の方法でマッチングする場合、かなり簡単に大量の時間と空間を 消費することを意味します。 正規表現を注意深く構築することは助けになりますが、かなりの場合これは 不十分です ("Mastering Regular Expressions" という本を読む必要があります; perlfaq2 を参照してください)。 空間の不足は Perl がメモリ不足になることで明らかになります。
ソート - 5.8.0 以前の Perl で sort() 関数を実装するために使われていた クイックソートアルゴリズムは、大量の時間を消費するような策略がとても 簡単でした。 Perl 5.8.0 から、異なったソートアルゴリズムであるマージソートが デフォルトで使われています。 マージソートは入力データによって影響を受けません。
さらなる情報については https://www.usenix.org/legacy/events/sec03/tech/full_papers/crosby/crosby.pdf および、 アルゴリズム的複雑性に関する情報工学の教科書を参照してください。
人気のあるツールである sudo は、 ユーザーが他のユーザーとしてプログラムを実行する制御された手段を 提供します。 これはある程度実行環境をサニタイズして、 シェバン競合条件 を回避します。 安全なバージョンの set-id スクリプトを持っていない場合、 sudo は、他のユーザーとしてスクリプトを実行するための、 C ラッパーを書くよりもより便利な手段になります。
しかし、sudo はターゲットの身元として set-id ビットが行うような 単なる実効 ID ではなく、実ユーザー ID やグループ ID を設定します。 結果として、Perl はこれが sudo の基で実行されていることを検出できず、 汚染チェックモードを友好にすると行ったセキュリティ上の予防措置を 自動的に有効にしません。 sudo 設定が実行されるコマンドを正確に設定する部分では、 perl が汚染チェックモードを有効にするために、承認されたコマンドに -T オプションを含むことができます。
一般的に、sudo の基で実効するためのスクリプトの適合性を評価することは、 特に想定している実行環境では必要です。 同じスクリプトに対して伝統的な set-id 配置で実行できるようにすることは 必要でも十分でもありませんが、多くの問題は重なっています。
"ENVIRONMENT" in perlrun には環境変数を洗浄する方法が記述されています。