Return-Path: owner-bugtraq-jp@SECURITYFOCUS.COM MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver 1.25.05 Message-ID: <3826A8B12F8.B54ASECURITY@210.157.158.132> Date: Mon, 8 Nov 1999 19:40:49 +0900 Reply-To: Artemis Security Team Sender: BUGTRAQ-JP List From: Artemis Security Team Subject: Archive Exploit(Re: Lhasa ver0.13 bufferOverflow Exploit) X-To: bugtraq-jp To: BUGTRAQ-JP@SECURITYFOCUS.COM Artemis Security Teamです。 　自己レスですみません。 個人的にkobayashiさんからフォローを頂いたのですが、 Lhasa exploit可能なバージョンを書き違えていました。 正しくは、ver0.13です。 おそらく0.11でも動作するとは思いますが、肝心のバージョンを書き間違える とは。。。検証中にバージョンが上がった為にやってしまったミスです(汗 　で、このzipファイルexploitですが、 同様の現象が、UNZIP32.DLLにも起きているようです。5.3で検証済みです。 オーバーフローするポイントは同じで、ちょっと作り方をかえれば Exploitコードを作るのは難しくないと思われます。 ※詳しくは言えないのですが、例外ハンドラ書き換えパターンで、即時解凍、 ディレクトリを作成して解凍によってオーバーフローが異なり、UNZIP32.DLL でも「ディレクトリを作成して解凍」がよりLhasaに近いと思います。ディレ クトリ作成部分が関わっている問題でしょう。ただ、EIPは取れるものの、ディレ クトリ作成パスにより、EIPがかなり異なってしまうため、実際に作成するには 別のアプローチが必要かもしれません。 　ですので、UNZIP32.DLLを使用している、つまり外部DLLに頼るタイプのアーカ イバ全てにバッファオーバーフローの危険性があるという事になります。 　更に、UNLHA32.DLLにも似たようなバグがありそうです。そのほか、tar、gzの 解凍ルーチンにも同じようなバグが存在します。これらはまだ検証したわけでは なく単に強制終了させる事が判明した程度ですが、ウィルスバスターがこれらの 「正しくないアーカイバ」を走査するとハングアップを起こすという事例もある ので真剣に考えるべきだと思います。 ------------------------------------------------- Artemis Security Team / ARTEMIS co,. ltd. E-mail : security@artemis-jp.com Web : http://www.artemis-jp.com/ -------------------------------------------------