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: <382652E121C.1CE9SECURITY@210.157.158.132> Date: Mon, 8 Nov 1999 13:34:41 +0900 Reply-To: Artemis Security Team Sender: BUGTRAQ-JP List From: Artemis Security Team Subject: Lhasa ver0.13 bufferOverflow Exploit X-To: bugtraq-jp To: BUGTRAQ-JP@SECURITYFOCUS.COM はじめまして。 Artemis Security Teamです。 ■定番ソフト「Lhasa ver0.11」に重大なセキュリティホール 　LHA、ZIPアーカイブファイル解凍ソフトの定番である「Lhasa ver0.11」最新版にセキュリティホールを発見しました。ローカルファイルヘッダのファイル名に長いファイル名を指定したzipファイルを解凍しようとするとバッファオーバーフローが発生します。 　これにより、exploitコードを含んだ長いファイル名を指定する事によって、解凍した段階でローカルの任意ファイル/コマンド/システムコールの実行、リモートより任意プログラムのダウンロード/インストール/実行を勝手に行なわせる事が可能になります。 　このExploitコードは通常、ファイルのダウンロードによってターゲットマシンへとコピーされます。このためファイルウォールやその他のネットワークフィルタリングは無効であり、またターゲットがWindowsであるため、UNIXとは違ってパーミッションの壁もないことから、ターゲットマシン上のどんなコードも実行可能となるので、セキュリティ上かなり危険な部類に入ると思われます。侵入経路としてはマクロウィルスなどと同様と考えるのが適当ですが、マクロウィルスとは違い、現時点では防ぐ事が出来ません。 ■内容 　Exploitコードを含んだZIPファイルはWindows側から見れば異常であり、通常のユーティリティでは作成する事すらできませんが、ZIPフォーマット上から見れば別に異常な形式というわけではありません。何故ならローカルファイルヘッダにおけるファイル名長さフィールドは２バイトで、ファイル名は可変となっている為、理屈上は0xffff(65535)バイトのファイル名を指定する事が出来るようになっているからです。 A. ローカルファイルヘッダ ローカルファイルヘッダシグネチャ 4 bytes(0x04034b50) 解凍に必要なバージョン 2 bytes 汎用ビットフラグ 2 bytes 圧縮方法 2 bytes 最後に更新された時間 2 bytes 最後に更新された日付 2 bytes 32ビット冗長度符号チェック値 4 bytes 圧縮時ファイルサイズ 4 bytes 解凍後ファイルサイズ 4 bytes ファイル名長さ 2 bytes 予備フィールド長さ 2 bytes ファイル名 可変 予備フィールド 可変 Fig.1 ZIPファイルのローカルファイルヘッダ構成図 　しかし、Windows上で扱えるファイル名長さは256バイトであり、Microsoft Visual C++6.0で決められている最大ファイル名長さを見てみると、 [ stdlib.hより抜粋 ] /* * Sizes for buffers used by the _makepath() and _splitpath() functions. * note that the sizes include space for 0-terminator */ #ifndef _MAC #define _MAX_PATH 260 /* max. length of full pathname */ #define _MAX_DRIVE 3 /* max. length of drive component */ #define _MAX_DIR 256 /* max. length of path component */ #define _MAX_FNAME 256 /* max. length of file name component */ #define _MAX_EXT 256 /* max. length of extension component */ #else /* def _MAC */ #define _MAX_PATH 256 /* max. length of full pathname */ #define _MAX_DIR 32 /* max. length of path component */ #define _MAX_FNAME 64 /* max. length of file name component */ #endif /* _MAC */ 256バイトとなっています。つまり、256バイト以上のファイルを解凍することは出来ないはずなのですが、そのチェックをしておらず、ZIPファイルの情報を信頼した作りになっている為か、そのままファイル名を読みこんでしまうようです。また、この時にファイル名を格納するバッファサイズは256(260?)バイトになっていると思われます。 　Lhasaをディスアセンブルした結果、ファイル名を格納する処理にstrcpy関数を使用している事がわかりました。ここで256バイトを超えた長大なファイル名を256バイトのファイル名格納用バッファにコピーしようとしてオーバーフローが発生し、それ以後のバッファがファイル名格納用バッファエリア以後のメモリエリア(retアドレス以降〜GPFダイアログボックス(バッファのある限り))を破壊します。そしてlstrcpyAの処理に失敗しているにも関わらず、その後の処理で破壊されたままのバッファを参照してCreateDirecroty関数が実行され、これも失敗しています。その後、破壊されたアドレスを参照しているポインタによる何らかのメモリ書きこみの処理が行なわれ、アクセス違反が起きるものと思われます。 LHASA のページ違反です。 モジュール : <不明>、アドレス : 0000:91919191 Registers: EAX=0065e438 CS=0177 EIP=91919191 EFLGS=00010246 EBX=0065e438 SS=017f ESP=00560018 EBP=00560038 ECX=005600bc DS=017f ESI=8172a290 FS=308f EDX=bff768d5 ES=017f EDI=005600e4 GS=0000 Bytes at CS:EIP: Stack dump: bff768c9 005600e4 0065e438 00560100 005600bc 005601f0 bff768d5 0065e438 005600cc bff8813d 005600e4 0065e438 00560100 005600bc 91919191 005602a8 　このような場合も例外ハンドラ書き換えにより、exploitコードの実行を行う事が出来ます。どのような理屈でそうなるのかは、Shadow Penguin SecurityのドキュメントNo.22の「Windowsアプリケーションソフトウエアにおけるスタックオーバーフローの危険性」を見てください。 http://shadowpenguin.backsection.net/docs/winstack.txt 　zipコードには、0x00を含む全てのコードが使用できるので、メモリにExploitコードが展開される位置(0x00430312)を直に指定しています。この位置はもしかするとOSのバージョンによって違うかもしれません。少なくともWindows98では実際に動作させることが出来ています。もし実行が出来なくてもアクセス違反が起きればEIP値の調整によりExploitコードを実行させる事が出来ると思われます。 　添付のプログラムは、Exploitコードを含んだzipファイルを作成します。これをLhasaで解凍させると、C:\aaa.comという小さな実行ファイルを作り、実行します。これは僅か21バイトのデモで、フルスクリーンでうねうねと謎の模様が現れますが、実害はありません。終了するにはALT+TAB等で抜けてaaa.comを強制終了させてください。 　ファイルを任意に作成、実行できるという事は非常に重大なセキュリティホールとなり得るのです。極端な話、ファイアウォールを突破する新しい手段として使われる可能性もあるということです。 ■対処方法 　まず第一に、strcpy関数を使用しない事です。これは昔からセキュリティホールの温床になっている関数ですので、これを使うのであればstrncpy関数を使用しなくてはなりません。また、ZIPファイルの汎用ビットフラグを見て、個々のＯＳに対応した最大ファイル名長さを適応するというのも１つの手といえるかもしれません。 　lstrcpyA関数を使用している部分でのエラー処理がないように思われます。また、CreateDirectory関数のエラー処理もないのではないでしょうか。システムコールを含めて全ての関数にはエラー処理をつけるべきでしょう。 　それから、ターゲットのファイルフォーマットを完全に信頼しない事が重要です。必ずしも正しい形式だとは限りませんし、正しいエラーチェックが出来ているとも限りません。現にLhasaもファイル形式の整合性を若干チェックしているようですが、こうしてセキュリティホールが出来てしまっているわけですから問題があるでしょう。 　このセキュリティホールがFixされるまでの対処方法としては、Lhasaを使わずに、Explzhなどのアーカイブの中身がわかるような解凍ソフトを使用し、解凍前に内容のチェックを行うか、信頼できないサイトからダウンロードしたアーカイブファイルを解凍しないことです。 　また、この問題は１０月２７日に「Lhasa」の開発者である竹村嘉人氏に報告を致しましたが現時点では返答がありません。次期バージョンでFixされる事に期待します。 ---- 　これらの一連のExploitを作成するにあたり、Shadow Penguin Securityにある資料をかなり参考にさせていただきました。ありがとうございます。 ---------------------------- Artemis Security Team security@artemis-jp.cpm ---------------------------- ARTEMIS co.,ltd. http://www.artemis-jp.com/