
SLMail 5.1における古典的なスタックベースのバッファオーバーフロー。初期のメールサーバーが過剰なサイズのSMTPおよびPOP3コマンドによってどのように侵害される可能性があるかを示しています。
SLMail 5.5 における古典的なスタックベースのバッファオーバーフロー。過剰なサイズの SMTP および POP3 コマンドにより、初期のメールサーバーがどのように侵害され得るかを示します。
このリポジトリは、メモリ破壊の悪用を教える際に使用する教材の一部です(本業に加えて、さまざまなサイバーセキュリティコースで講師を務め、次世代のリバースエンジニアを育成しています)。
CVE-2003-0264 は、ネットワークプロトコルを介したバニラなスタックベースのバッファオーバーフローを教える際に最初に紹介する事例の一つです。問題は明確で、文書化も十分であり、悪用の経路も直接的です。SEH もエッグハンターもスペースの制約もありません。学生はペイロードを送信し、EIP を上書きし、JMP ESP ガジェットに着地させ、シェルを取得します。この明快さこそが、出発点として有用である理由です。
SLMail 5.5 はレガシーな Windows メールサーバーです。この脆弱性は POP3 サービス、特に PASS コマンドハンドラに存在し、ユーザー入力が固定サイズのスタックバッファに長さチェックなしで直接コピーされます。このケースが教育に特に有用なのは、可動部分が極めて少ない点にあります。
これらの組み合わせ(ネットワーク公開、認証不要、EIP の直接上書き、最新の緩和策なし)により、CVE-2003-0264 は最新の Windows バージョンでも動作するバニラスタックオーバーフローの最もクリーンな実世界例の一つとなっています。
SLMail は Windows メールサーバーであり、SMTP、POP3、管理サービスを提供します。POP3 サービスは TCP ポート 110 で待機し、標準的なメール取得コマンドを処理します。脆弱性は PASS コマンドハンドラにあり、接続クライアントから送信されたパスワード引数を処理します。
主な技術的詳細:
SLMail の POP3 サービスは、PASS コマンドを処理する際に、提供されたパスワード引数を安全でない関数を使用して固定サイズのスタックバッファにコピーします。長さチェックは行われません。脆弱なロジックの簡略版は次のようになります:
char password_buffer[256];
strcpy(password_buffer, pass_argument);
PASS 引数として十分に長い文字列を送信すると、コピーがバッファの末尾を超えて書き込まれ、保存されたリターンアドレスが上書きされるまでスタックが破壊されます。関数が戻るとき、CPU はスタックから攻撃者制御の値を EIP にロードし、そこにジャンプします。
クラッシュは、POP3 経由で過剰なサイズの PASS 引数を送信することで再現できます。有効な資格情報は必要ありません。Python を使用した例:
import socket
HOST = '127.0.0.1'
PORT = 110
payload = b"A" * 3000
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((HOST, PORT))
s.recv(1024)
s.send(b"USER username\r\n")
s.recv(1024)
s.send(b"PASS " + payload + b"\r\n")
s.close()
デバッガで実行すると、クラッシュ時に EIP がユーザー制御のデータで上書きされていることがわかります:
EIP = 41414141
これにより、保存されたリターンアドレスがオーバーフローによって破壊されたことが確認されます。
このリポジトリの目的は、クラッシュのデモンストレーションだけでなく、ファジングから動作するリバースシェルに至るまでの完全な悪用プロセスを段階的に説明することです。
メインの README を簡潔に保つため、詳細な悪用ノート、スクリプト、デバッガの手順は、このリポジトリの Vulnerability 📂 フォルダに配置されています。
そこには、この CVE を悪用するために使用した完全なワークフローが含まれており、以下の内容があります: