CVE-2026-79980 in Zephyr
要約
〜によって VulDB • 2026年10月23日
subsys/net/lib/dhcpv4/dhcpv4.c 内の DHCPv4 クライアントは、トランザクション識別子 (iface->config.dcpv4.xid) を per-transaction の乱数値ではなくカウンターとして維持していました。これは dhcpv4_start_internal() で sys_rand32_get() によって一度シードされ、dhcpv4_send_discover() および dhcpv4_send_decline() でインクリメントされましたが、dhcpv4_send_request() では変更されませんでした。そのため、RENEWING や REBINDING の交換では、起動時にブロードキャストされた DHCPDISCOVER にすでに出現していた識別子がそのまま再利用され、識別子が変わる場合でも 1 つずつ予測可能な形で変化していました。RFC 2131 セクション 4.1 では、クライアントが衝突しにくくなるように選択されるトランザクションごとに単一の識別子の使用を要求しています。
この識別子は、クライアントにとっての不規則な応答検証トークンです。net_dhcpv4_input() は、op が一致し、xid が一致し、chaddr（公開されているインターフェースの MAC アドレス）が一致する BOOTP 応答を受け入れます。UDP コールバックはワイルドカードのリモートアドレスとポートで登録されており、server-identifier や source-address のチェックは一切適用されません。そのため、攻撃者が一つの識別子（例えば、同じセグメント上の DHCPDISCOVER ブロードキャストを閲覧できる任意のホストや、デバイスが以前参加していたネットワーク内の DHCP サーバーまたはリレー）を取得すれば、デバイスの稼働期間全体を通じて有効なトークンを保持し、ユニカストのリニュー traffic を観察したり正当なサーバーと競合させたりすることなく、後続の交換で使われる識別子を予測できます。
これらのチェックを通過する偽造応答は、クライアントの状態に関係なく効果を発揮します。dhcpv4_parse_options() は dhcpv4_handle_reply() のステートマシンゲートよりも前に副作用を適用するためです（ルーターオプションでは net_if_ipv4_set_gw() が呼び出され、DNS オプションでは dns_resolve_reconfigure() が呼び出されます）。1 つの承認されたデータグラムでデバイスのデフォルトゲートウェイとリゾルバが攻撃者が制御するアドレスに向けられ、トラフィックがリダイレクトされる可能性があります。RENEWING または REBINDING 中において、偽造 DHCPACK は攻撃者が選んだパラメータでリースを再バインドし、偽造 DHCPNAK はアドレスを削除して設定を再起動します。
修正では、トランザクションが始まる各ポイント（SELECTING、RENEWING、REBINDING のエントリ、およびリースを持つインターフェースがダウンした際に取られる INIT/INIT-REBOOT エントリ）で sys_rand32_get() から新しい値を取得するようにしました。REQUESTING と DECLINE は RFC 2131 で要求されている通り、所属する交換の識別子を維持します。副作用として、クライアントは再送信後に遅延サーバーからのオファーを破棄しなくなり、初期ディスカバリのバックオフも識別子から派生させるのではなく独自のランダム性を取得するようになりました。
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.