■ShellExecute()の落とし穴 (プログラム)

_ ShellExecute() APIの解説に、以下の記述がある。

フォルダを開くには、次のコードを記述します。
ShellExecute(handle, NULL, path_to_folder, NULL, NULL, SW_SHOWNORMAL);

_ このコードで、フォルダが開かないケースがひとつある。「フォルダと同じベース名の実行可能ファイルがあるとき」がそれ。

_ たとえば、フォルダ"C:\temp\test"を上のAPIで開くとき、「ShellExecute(handle, NULL, "C:\\temp\\test",〜)」とするわけだ。しかし、もしこのときに"C:\temp\test.exe"とか"C:\temp\test.bat"とかが存在していると、フォルダを開かずにそっちを実行してしまう。

_ これは、プログラムを書かなくても検証できる。コマンドラインから、以下のように実行してみるとよい。"start hoge"でフォルダを開かず、hoge.batを実行しているのがわかるはず。

mkdir hoge
echo date>hoge.bat
start hoge

_ これ単体では「困った仕様だな」程度だが、ちょっと前にあった「圧縮ファイル解凍の脆弱性」と組み合わせられると、危険な穴になる。

_ "test.lzh"という圧縮ファイルがあったとする。Windowsでこのファイルをダブルクリックすると解凍ツールが起動し、デスクトップなどに"test"というフォルダが作られて中身が解凍されたあと、このフォルダが開かれるようになっているのが一般的である。ところが、この圧縮ファイルに"../test.exe"というファイルが含まれていると、どうなるだろうか。

_ 脆弱性が修正されていない解凍ツールでこれを開いた場合、「フォルダ"test"を作る」「ファイル"test/../test.exe"を解凍する」「フォルダ"test"を開く」という動作をしようとして、最後の「フォルダ"test"を開く」ところが「ファイル"test/../test.exe"を実行する」になってしまう。

_ つまり、「圧縮ファイルを解凍しただけのはずが、中身を実行してしまう」という事態が発生してしまうわけだ。危険この上ない。

_ 幸い、「圧縮ファイル解凍の脆弱性」が公開されてからかなり時間が経っているため、穴はすでに塞がれており、こういうことはそう起こらないはず。環境のアップデートをちゃんと行っていればだが。

_ ただ、これと同種の「フォルダを作成し、その中にファイルを生成し、最後にそのフォルダを開く」という動作をするプログラムは、同種の罠にはまる可能性がある。また、フォルダやファイルの作成をしなくても、「どこかのデータフォルダなどを開く」プログラムは、そのフォルダと同名の実行可能ファイルを外部から配置されることで、「フォルダを開く」作業をしたつもりが「ファイルを実行させられてしまう」可能性がある。

[URL]

[View Log(0)]

[Trackback]

Name: Comment: