MOPB-23-2007:PHP 5 Rejected Session Identifier Double Free Vulnerability

Pythonも危ない…

MOPBでPHPのセキュリティホールばかり書いているので「PHP本体のコード、最低だね」と思われているかも知れません。他の言語でも「最低」なコードは探せば いくつでも見つかると思います。今日、full-disclosureに投稿された記事です。

Description:

The source of python contain a various modules, the zlib module contain a minigzip tool, ( * minigzip is a minimal implementation of the gzip utility. ).

Source error:

the error was found in:
– void file_compress(file, mode)
because the use of strcpy() is inapropriatly

—
#define MAX_NAME_LEN 1024
[..]
void file_compress(file, mode)
char *file;
char *mode;
{
local char outfile[MAX_NAME_LEN];
FILE *in;
gzFile out;

strcpy(outfile, file);
strcat(outfile, GZ_SUFFIX);
—

the function file_compress() was called by main() function.

Proof of concept:

if you want test the vulnerability try:
$ minigzip `perl -e “print ‘A’x1050″`

— starcadi

教科書に書いてあるstrcpy()スタックバッファオーバーフローに脆弱です。固定バッファ＆長さチェック全くなし…. そう言えばMOPBでもこれとほぼ同じ脆弱性が解説されています。偶然なのか、関連があるのか興味があるところです。

（備考：もしかすると作者はファイル名が関数にわたるまでに開いてみるので長すぎるファイル名は渡せない、と考えたのかも知れません。作者のシステムではMAX_NAME_LENとシステムの最大パス名が同じだったのかも知れません。いずれにせよ、危険なコードを書いてしまう考え方です）

モジュール作者の能力の問題もあるかも知れませんが、スクリプト系言語とは言えプログラミング言語なので「自分で自分の首を絞める」ようなコードには対応していない場合も多いと思います。バッファオーバーフロー脆弱性を使わなくてもスクリプトだけでいくらでも悪意をもった行為が行えます。言語なので多少のバッファオーバーフローくらいは問題にならない、と考えている開発者も多いと思います。言語とその言語のモジュール型ライブラリにどの程度のセキュリティを達成させるか?微妙な問題です。

しかし、一つ一つは小さな問題（このPythonの脆弱性も重要度としては「中」レベル）でもスクリプト系言語とそのモジュールはメモリ管理エラーが無い方が望ましいと思います。小さな脆弱性でも組み合わせて重大な影響を与える攻撃が可能になる場合は多いです。Pythonの場合、バッチではなくGUIアプリケーションも多いのでユーザがZIPファイルを開いたら、攻撃コードが実行された（例えば、4321ポートで接続を待つ）などとなりかねないです。Webの場合も同じようにZIPファイルを扱うアプリには、同様の攻撃が行えるかも知れません。

PHPの場合、特殊で多くの共有型Webホスティングサービスで利用可能である事、「自分で自分の首を絞める」コードにもある程度対応してしまっている事から問題を複雑にしています。この結果、PHPの場合は他の言語よりも高いレベルのセキュリティを求められていると思います。

以前、mod_phpと悪意を持った外部プログラムを組み合わせて利用するとApacheのログの読み書きが自由に行える脆弱性が公開されていました。アドバイザリではmod_phpだけ記載されていましたが、この脆弱性もmod_phpに限ったことではありません。mod_python, mod_perl, mod_rubyでも同じ事が可能です。

Month of Python/Perl/Ruby Bugs (Python/PerlはMOPBですね）してくれないかな…

想像力と鈍感力

少し前になりますが小泉前首相が安部首相に対して「鈍感力も大事」と言っていましたが、良い事を言うなあ、と思って聞いていました。「鈍感力」は日常生活でも必要不可欠です。

例えば、道を歩いているだけでも交通事故合うかもしれないです。飛行機に乗ると墜落するかも知れません。もしかすると寝ていても隕石が落ちてきてあたるかも知れません。隕石に当たって死亡する事を心配する人はいないと思いますが、交通事故や飛行機事故を心配する人は多いと思います。可能性を考えすぎると怖くて何も出来なくなります。

コンピュータを使っていても同じです。ネットワークを盗聴されているかも知れません。OSにセキュリティホールがあるかも知れません。ブラウザにセキュリティホールがあるかも知れません。Webサイトにもセキュリティホールがあるかも知れません。可能性を考えすぎると怖くて使えなくなります。

コンピュータの利用には非常に多くのリスクが存在します。CVEに登録・公開されているセキュリティホールはほんの一部で氷山の一角でしかありません。ソフトを全て最新版にしても新しいバージョンに新たなセキュリティホールがあるかも知れません。あり得ないですが仮に「ソフトが全部安全」だとしてもハードウェアに仕組まれた「ソフト（ファームウェア）」に攻撃コードが含まれているかも知れません。コンピュータを実際に利用するには「鈍感力」がないと利用できないほどリスクが沢山あります。

しかし、ソフトウェア開発者にはセキュリティ「鈍感力」は（あまり）必要ありません。「鈍感力」より「想像力」が必要です。ここで間違えるとセキュリティ上の問題になるかも！この仕様だと他の仕様と組み合わせるとセキュリティホールになるかも！と想像できないとならないです。だれであっても、どれだけ経験・知識があっても、どんなに想像力があっても、全ての脆弱性を想像する事は不可能です。

開発者は「想像力」豊かに、利用者は（ある程度）「鈍感力」を持って、コンピュータを利用する必要があります。
# 開発者・利用者ともに「鈍感力」を鍛えすぎ、かな….

セキュリティ用語の統一化

偶然ではないかも知れませんが、同じ時期に同じような物がリリース/改定するとアナウンスされています。

http://cwe.mitre.org/data/dictionary.html
（こちらはDraft5）

http://www.webappsec.org/lists/websecurity/archive/2007-03/msg00041.html
（2.0への改訂作業者募集）
http://www.webappsec.org/projects/threat/
（こちらは1.0)

どの世界でも同じと思いますが用語の使い方は結構適当（いい加減）、同じ事の言い換え（別名）、範囲が不明確（部分集合、etc）など、いろいろ問題もあります。これらが在るとコミュニケーションは行いやすくなります。専門家にとってはあまり苦にならないと思いますが、CWEを全部読んで覚えるのは一般開発者には結構大変かも、と思いました。