見出し画像

【lwIP】News #1｜2026年セキュリティ監査で13件の脆弱性報告？｜公開済みSMTPバッファオーバーフローを確認

lwIPトラブル対策室(lwIP Lab)

(English Version Here.)

このnoteでは、lwIPで実際に起こり得る不具合・脆弱性・再現方法・最小修正の考え方やデバッグのノウハウをシリーズで解説しています。
▶ 日本語記事一覧はこちら：lwIPトラブル対策室｜日本語記事一覧

本記事は「News」として、lwIPに関する速報・重要な動向をお届けします。News記事は、基本的に自分で再現・解析した内容ではなく、外部で公表された情報の整理・注意喚起が中心です。個別の脆弱性を深掘りする場合は、後続のBug/Tips/Guide記事として別途扱います。

■ 今回のニュース概要

2026年、lwIPを対象としたセキュリティ監査の結果として、13件の脆弱性が報告されたとするGitHubリポジトリが公開されています。

  • リポジトリ：xchglabs/lwip-2026-pocs

  • 対象バージョン：lwIP v2.2.1（`STABLE-2_2_1_RELEASE`）および `master`

このうち1件は、リポジトリ上でSavannah Bug #68313として示されており、lwIP本家masterにも関連する修正が反映されています。ただし、2026年6月15日時点でSavannahの該当ページは閲覧できない状態のため、本記事では公開リポジトリとlwIP本家ソースで確認できる範囲に限定して整理します。残り12件は、リポジトリの説明によると「lwIPメンテナーへ報告済みだが未公開」とされています。

本記事では、現時点で公開されている1件（SMTPクライアントのバッファオーバーフロー）について、公開ソースコードをもとに内容を確認します。残り12件については、このリポジトリ上では詳細が公開されていないため、内容の評価ができません。

■ 何が報告されたのか（公開リポジトリの構成）

リポジトリは、脆弱性ごとにディレクトリが分かれており、各ディレクトリには以下が含まれています。

  • `README.md`：脆弱性の概要

  • `setup.sh`：検証環境構築用スクリプト

  • `harness/`：再現用のテストハーネス

  • `standalone/`：単体で動作する再現コード

  • `patch/`：修正案の差分ファイル

対象範囲としては、SMTPクライアント・DNSリゾルバ・DHCP・HTTP/MQTT/SNMPの各アプリケーション・コアIPスタックなど、lwIPの広い範囲に及ぶとされています。ただし、xchglabs/lwip-2026-pocsリポジトリ上で詳細を確認できるのは、現時点では公開済みの1件のみです。他のlwIP関連の脆弱性情報が別経路で公開されている可能性はあるため、本記事ではこのリポジトリで確認できる範囲に限定して整理します。

■ 公開済みの脆弱性：SMTPクライアントのtx_bufバッファオーバーフロー（Bug #68313）

公開済みの1件は、SMTPクライアントの認証応答処理に関するバッファオーバーフローです。リポジトリ上では、Savannah Bug #68313として示されています。

なお、本記事では公開情報に基づく概要整理に留めます。PoCの実行手順や詳細な再現条件、パッチ適用時の注意点については、必要に応じて別のBug記事で扱います。

ソースコードで確認できたこと

`src/apps/smtp/smtp.c` の `smtp_prepare_auth_or_mail()` 関数では、SMTPサーバーから受信した `AUTH ...` 応答行を、固定長バッファ `tx_buf` にコピーする処理があります。

`tx_buf` は次のように定義されています（`SMTP_TX_BUF_LEN` は255）。

char tx_buf[SMTP_TX_BUF_LEN + 1];

コピー処理は以下のようになっています。

u16_t copied = pbuf_copy_partial(s->p, s->tx_buf, (u16_t)(crlf - auth), auth);
s->tx_buf[copied] = 0;

`crlf - auth` は、受信した応答行のうち「`AUTH `（または`AUTH=`）の直後からCRLFまでの長さ」であり、サーバーが応答として送ってくる値そのものです。`tx_buf` の配列サイズは `SMTP_TX_BUF_LEN + 1`（256バイト）ですが、末尾にNUL文字を書き込むため、コピーしてよい上限は `SMTP_TX_BUF_LEN`（255バイト）です。この上限に合わせたクランプ（上限カット）が、コピー前に行われていません。

lwIPのSMTPクライアント機能（`apps/smtp`）はlwIP 2.1.0で追加されたもので、それより前の2.0.x系には含まれていません。確認した範囲では、2.1.0〜2.2.1の `smtp.c` はいずれも、上記と同じ未クランプの構造でした。

影響範囲

  • SMTPクライアント機能（`apps/smtp`）を使用しており、`SMTP_SUPPORT_AUTH_PLAIN` または `SMTP_SUPPORT_AUTH_LOGIN` が有効な構成で該当します。手元で確認したlwIP本体の `smtp_opts.h` では既定で有効ですが、実際の有効/無効は使用しているlwIP本体やベンダーSDKの設定ファイルで確認してください。

  • 通常の利用シーンでは、機器が接続するSMTPサーバー側からの応答が起点になります。接続先のSMTPサーバーが悪意のあるもの、または通信経路上で応答が改ざんされる状況であれば、想定より長い応答行によってバッファオーバーフローが発生する可能性があります。

  • 公開リポジトリの解説によると、この処理はSMTP認証情報を送信する前のEHLO応答処理で行われるため、機器側でSMTP認証を設定していない場合でも、サーバー応答中のAUTH行を解析する段階で問題が発生し得るとされています。

公開記事で指摘されている到達条件と影響

xchglabs/lwip-2026-pocsリポジトリと同じ著者によるブログ記事（xchglabs.com）では、この問題についてより詳しい解説が公開されています。

この記事によると、問題はSMTP認証情報の送信前、EHLO応答中の`AUTH`行（capability line）を解析する段階で発生すると説明されています。そのため、機器側でSMTP認証情報を設定していない場合でも、接続先SMTPサーバーからの応答に長い`AUTH`行が含まれていれば問題が発生し得るとされています。到達条件としては、lwIPのSMTPクライアントが接続する任意のSMTPサーバー、または通信経路上で応答を改ざんできる中間者が想定されており、STARTTLSを使用していてもサーバー証明書の検証が行われていない構成は対象になり得るとされています。

また、影響は単なる送信失敗やクラッシュに留まらない可能性も指摘されています。`tx_buf`の後ろには、受信`pbuf`へのポインタ、送信元・宛先・件名・本文を指すポインタと長さ、完了時に呼ばれるコールバック関数ポインタなどが続きます。これらが書き換わることで、後続の処理が想定外の挙動になる可能性があるとされています。実際の影響は、`smtp_session`がメモリ上のどこに配置されるか、対象環境のメモリ保護機構、ビルド設定、周辺のメモリ配置によって変わります。本記事ではPoCや攻撃手順の詳細には踏み込まず、利用者が確認すべき影響条件と修正方針に絞って扱います。

修正方針

リポジトリの修正案（`smtp_txbuf_clamp.diff`）は、コピー前に長さを `SMTP_TX_BUF_LEN` でクランプするという最小修正です。

u16_t auth_line_len = (u16_t)(crlf - auth);
u16_t safe_len = (auth_line_len < SMTP_TX_BUF_LEN) ? auth_line_len : SMTP_TX_BUF_LEN;
u16_t copied = pbuf_copy_partial(s->p, s->tx_buf, safe_len, auth);

実際にlwIP本家リポジトリでも、2026年5月12日付けのコミット（`614420f`）でコピー長を `SMTP_TX_BUF_LEN` 以内に抑える修正が `master` に反映されています。ただし、2026年6月15日時点では、この修正を含む新しい正式リリースタグはまだ確認できていません。最新の正式リリースタグは2.2.1であり、2.2.1をそのまま利用している環境では別途修正の取り込みを検討する必要があります。

■ 確認しておきたいポイント

  • お使いのlwIPに `src/apps/smtp/smtp.c` が含まれているか（SMTPクライアント機能を使っていない場合は影響しません）

  • `SMTP_SUPPORT_AUTH_PLAIN` / `SMTP_SUPPORT_AUTH_LOGIN` の設定（lwIP本体のsmtp_opts.hでは既定で有効。ベンダーSDKの設定ファイルで実際の値を確認）

  • 機器が接続するSMTPサーバーが信頼できる相手か、通信経路上で応答が改ざんされる可能性がないか

  • STARTTLSを使用している場合でも、SMTPサーバー証明書の検証を行っているか（lwIP SMTPクライアントのTLS連携設定は環境依存のため、自分の環境で確認が必要です）

  • 上記のコミット内容を参考に、自分の環境のソースに同様のクランプ処理を追加できるか

■ 公式対応状況・要確認事項

  • lwIP本家： コミット `614420f`（2026年5月12日）で `master` には修正が反映済みです。ただし、2026年6月15日時点では、この修正を含む新しい正式リリースタグは確認できていません。

  • Savannah Bug #68313： リポジトリ側の記載では「Disclosed（公開済み）」となっていますが、2026年6月15日時点でSavannahの該当ページにアクセスすると「Permission Denied（非公開アイテムのため閲覧不可）」と表示されます。この点は要確認です。

  • 関連するSavannah Bug #68397： 2026年5月、CISAがSploitus上で公開されている「lwIPに関する複数の脆弱性」の報告を確認し、協調的開示の趣旨でlwIP側へ連絡した内容が、Bug #68397として登録されています。このページ自体は公開されており、閲覧可能です。元の報告では、詳細確認のためにVINCE上での確認が案内されています。lwIPメンテナーのErik Ekman氏は2026年5月26日のコメントで「Fixed in bug #68313」と回答し、Bug #68397はDuplicate（重複）としてクローズされています。これは、少なくとも公開されているSMTPクライアントの問題について、Bug #68313側で対応されたことを示す公開情報です。なお、この通報で言及されているCERT/CCの脆弱性ノート「VU#129944」自体は、2026年6月15日時点で`kb.cert.org`上に該当ページが見つからず、内容の詳細は確認できていません。

  • CVE： 2026年6月15日時点では、このSMTPクライアントの問題に対するCVE番号の割り当ては確認できていません。なお、lwIP 2.2.1に関する別の脆弱性情報として、SNMPv3 USMハンドラのスタックバッファオーバーフロー（CVE-2026-8836）がNVDに登録されていますが、本記事で扱うSMTPクライアントのAUTH応答処理とは別件です。混同しないよう注意してください。

  • 残り12件： xchglabs/lwip-2026-pocsリポジトリ上では詳細未公開のため、内容・深刻度ともに評価できません。今後公開された場合は、改めて個別記事で取り上げる予定です。

■ 今後の展開

今回紹介した「2026年セキュリティ監査」の残り12件が公開された場合や、Bug #68313に関連する修正がlwIPの正式リリースタグに含まれた場合は、改めてNewsまたはBug記事として取り上げます。

また、本記事で紹介したSMTPクライアントのバッファオーバーフローについて、より詳細な再現手順やコード解析に興味がある場合は、今後のBug記事で扱う可能性があります。

■ 本記事の取り扱いについて（免責事項）

  • 目的： 本記事は、公開されている情報をもとに、lwIPのセキュリティに関する動向を紹介し、利用者の注意喚起・確認ポイントの整理を目的としています。

  • 検証： 本記事の内容は、公開リポジトリの記述およびlwIP公開ソースコードの確認に基づくものです。第三者リポジトリの記述内容そのものの正確性については保証できません。

  • 自己責任： 修正の適用や対応の判断にあたっては、各プロジェクトの要件に基づき、利用者自身の責任において十分な検証を行ってください。

  • 免責： 万一、本記事の情報に基づいて生じた損害やトラブルについて、筆者は一切の責任を負いかねます。

■ 最後に

今回は、2026年に報告されたlwIPのセキュリティ監査結果のうち、公開されているSMTPクライアントのバッファオーバーフローについて、公開ソースコードをもとに確認しました。

lwIPは広く使われているOSSであるため、今後も同様の脆弱性報告が公開される可能性があります。Newsシリーズでは、こうした外部の動向を整理し、必要に応じて個別の記事で深掘りしていく予定です。

lwIPは無料で手軽に製品に組み込める反面、利用する際にはバージョンや設定、既知の問題を把握しておくことが重要です。
また、商用製品のような保証付きサポートが前提ではないOSSであるため、最終的にはメーカー自身で不具合や脆弱性に対応しなければなりません。
そのため対応コストが製品出荷後に増大するリスクについても考慮しておく必要があります。

OSSであるlwIPには多くの利点がありますが、長期保守やサポート体制が重要な製品では、商用スタックを選択するケースもあります。

ただし、すでにlwIPで開発中の製品や出荷済みの製品を今から置き換えることは現実的ではありません。
そういった方に向けて、本記事の情報が、

  • 不具合や脆弱性の早期発見

  • 原因特定の時間短縮

  • 対応コストの低減

の参考になれば幸いです。

今後も、lwIPの問題に対して実用的な情報を公開します。

▶ 日本語記事一覧はこちら：lwIPトラブル対策室｜日本語記事一覧

いいなと思ったら応援しよう！