ION-DTNのDGRにヒープ破壊の脆弱性、修正版あり
NASA JPLのION-DTNのDGR通信層に、ヒープを壊されてサービス停止やコード実行に至る恐れのある脆弱性が見つかりました。DGRを使う環境は修正版へ更新し、IPCや独自の通信方式で使う場合を優先して確認してください。
急ぎ度: 早めに
CVSS v3は8.1、CVSS v4は9.2と高く、修正版の4.2.1-a.2がすでに公開されているため、DGRを使う環境は早めの更新が妥当です。
関係があるか
ION-DTNを運用し、Bundle ProtocolやAMSの通信にDGR（Datagram Retransmission）を使っている組織が対象です。DGRをIPCや独自の通信方式で動かしている構成は、特にリスクが高いとされています。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| ION-DTN（NASA JPL） | 2.2.1b以上4.2.0以下 | 4.2.1-a.2 |
確かめ方
- 1稼働中のION-DTNの版を、導入時の記録やビルドに使ったソースの版で確認し、2.2.1b以上4.2.0以下に当たるかを見る。
- 2Bundle ProtocolやAMSの設定で、DGRを通信方式に使っているかを確認する。
- 3DGRをUDPの上で動かしているのか、IPCや独自の通信方式で動かしているのかを区別する。
- 4自社のコードがdgr_receiveを直接呼んでいないか、同梱のdgr2fileを使っていないかを調べる。
何が起きたか
ION-DTNのDGR通信層に、細工されたデータを受け取るとメモリ領域が壊れ、サービス停止やコード実行に至る恐れのある脆弱性があります。
原因は2つの不備が連なっていることです。まず、受信データの長さを64ビットの値として読み取り、そこから32ビットの確保サイズを計算するときに、上限を調べていませんでした。極端に大きな値が来ると計算結果が一周してしまい、必要な量よりはるかに小さい領域しか確保されません。次に、dgr_receiveが読み取った長さをそのまま信じ、呼び出し側のバッファ容量を確かめないままmemcpyでコピーしていました。小さい領域に大きなデータが書き込まれ、範囲外への書き込みが起きます。
弱点の種類はCWE-190（整数オーバーフロー）とCWE-787（境界外書き込み）です。GitHubのセキュリティアドバイザリは2026年11月7日付で、VulnCheckは11月9日付でCVE-2026-124001として公開しています。
攻撃の流れ
-
1
細工データ送信
極端に大きな長さの値を持つDGRのデータが、受信側に届く。
-
2
サイズ計算が一周
64ビットの長さから32ビットの確保サイズを求める計算が桁あふれし、小さな値になる。
-
3
小さな領域を確保
必要な量よりはるかに小さいヒープ領域が確保される。
-
4
上限なしでコピー
dgr_receiveがバッファ容量を確かめないまま、元の長さでデータをコピーする。
-
5
ヒープ破壊
範囲外への書き込みでサービス停止、場合によってはコード実行に至る。
どう悪用されるか
CVSS上の前提は、ネットワークから攻撃でき、認証も利用者の操作も要らないことです。ただし攻撃の難しさは高いと評価されています。
標準的なUDPでの運用では、ネットワークの読み取り上限が受信データの大きさを自然に抑えるため、遠隔からの悪用はおおむね防がれていたと、開発側は説明しています。一方で、この上限を通らない経路では引き起こせます。ローカルからの入力や、UDP層の制約を迂回する合成データグラムがその例です。DGRをIPCや独自の通信方式で使っているシステムは、悪用されるリスクが高いとされています。
悪用に成功すると、ヒープが壊れてサービス拒否になるか、コード実行に至る可能性があります。CVSSは機密性・完全性・可用性のすべてを高と評価しています。
今すぐやること
-
1
版とDGRの利用状況を洗い出す
稼働しているION-DTNの版と、DGRを使っているノードを一覧にします。IPCや独自の通信方式でDGRを使っているノードを先に見つけておくと、更新の順番を決めやすくなります。自社のソースがdgr_receiveを呼んでいないかも、あわせて探します。
grep -rn "dgr_receive" /path/to/your/source -
2
4.2.1-a.2へ更新する
修正版では、割り当て前にINT_MAXを基準にした長さの検査が入り、宣言された長さが実際の受信量を超えるデータは拒否されます。dgr_receiveは宛先の容量を引数で受け取り、超過する書き込みを中止します。BP、AMS、同梱のdgr2fileは、実際のバッファサイズを渡すように更新済みです。
-
3
自作コードの呼び出しを直す
dgr_receiveの引数に容量が加わったため、自社のコードが直接呼んでいる場合は、新しい引数に合わせた修正とビルドのし直しが要ります。呼び出し側が渡す容量は、確保したバッファの実際の大きさにそろえます。
-
4
更新後に動作を確認する
検証環境でDGR経由の通信が従来どおり届くかを確かめてから、本番へ展開します。更新前の運用では、ION関連プロセスが予期せず異常終了していないかもログで見ておきます。
-
5
ベンダーの告知を確認する
実際の攻撃での悪用状況や追加の情報は、NASA JPLのION-DTNのセキュリティアドバイザリと、4.2.1-a.2のリリースノートで確認してください。
すぐ更新できないとき
回避策は案内されていません。更新までのつなぎとして、DGRに届く入力経路を絞ることが考えられます。IPCや独自の通信路に書き込める主体を信頼できるものだけに限り、外部から直接データを流し込める経路が残っていないかを点検します。これは一般的な縮小策で、脆弱性そのものを防ぐものではないため、修正版への更新が前提です。
背景
ION-DTNは、NASA JPLが開発しているBundle Protocolの実装です。通信が途切れたり遅れたりしやすい環境で、データを中継ノードに蓄えながら先へ運ぶ遅延耐性ネットワーク（DTN）を構成します。DGRはその下で再送の仕組みを担う通信層で、BPやAMSがデータの受け渡しに使います。
今回の脆弱性は、受信データが申告する長さの扱いが原因です。長さの検査が各層で別々に行われており、呼び出し側が容量を渡す仕組みもありませんでした。標準のUDP運用では読み取り上限が歯止めになっていたため、問題が目立ちにくかったと考えられます。修正が検査の追加だけでなく、dgr_receiveの引数の変更と、BP・AMS・dgr2fileすべての更新に及んでいるのは、そのためとみられます。
よくある質問
Q.GitHubはCVSS 8.1、VulnCheckは9.2と評価しています。なぜ違うのですか。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
影響パッケージ
| パッケージ | 影響を受ける版 → 修正版 | |
|---|---|---|
| nasa-jplION-DTN |
2.2.1b 〜 4.2.0→ 記載なし |
記載なし |
この記録には修正版の版が載っていません。修正版の有無と版は、本文か参照URLのベンダーの勧告で確かめてください。
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
NASA JPL ION-DTN 2.2.1b through 4.2.0 contains an integer overflow vulnerability in the Datagram Retransmission (DGR) convergence layer that allows attackers to corrupt heap memory by sending a maliciously crafted 64-bit svcDataLength value that wraps a 32-bit allocation size calculation. Attackers can exploit the dgr_receive API's unchecked memcpy operation using synthetic datagrams or DGR traffic over internal IPC or custom transports to trigger an out-of-bounds write, leading to denial of service or potential remote code execution.
出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory
参照URL
- advisory github.com
- advisory vulncheck.com
- advisory github.com
- advisory nvd.nist.gov
- package github.com
- patch github.com