編集長の佐藤（@akihirosato1975）です。
弊社のサービス統括部（いわゆるDevOps部署）には「セキュリティ対策室」なんてものがありまして、一応私もそこのメンバーの一員だったりします。
なので定期的にUS-CERTやJVNなどの脆弱性レポートをチェックして、社内で使われていそうなソフトについては開発者向けにアナウンス出したりといったことをやっているわけですが、今日はそんな中から一つ引っかかったネタが。
元ネタは CVE-2016-10142 なんですが、斜め読みすると「IPv6にプロトコルレベルで脆弱性がある」ように読める上、CVE番号でGoogle検索かけても日本語の情報がほとんどないという。
実際にはまだナビ社内ではIPv6はほとんど使ってないんですが、気になったので「Overview」だけでもざっくり翻訳してみました。
＃たぶん翻訳ミスありそうな気がするのでご指摘お待ちしてます。
IPv6プロトコルにおいて、ICMP PTB（Packet Too Big）メッセージに関連する問題が発見された。（このCVEは全てのベンダから出ているIPv6実装を対象としている）
IPフラグメンテーションのセキュリティ実装は RFC6274 と RFC7739 において長々と説明されている。
攻撃者は、任意のIPv6フローにおけるフラグメンテーションの利用をトリガーに、IPv6アトミックフラグメントの生成を倍加することができる（シナリオにおいては、パケットのフラグメンテーションが実際に起こっている必要はない）。
その結果 RFC6946 を実装していないレガシーなIPv6ノードに対して、あらゆるタイプのフラグメンテーションベースの攻撃を実行できる。
つまり、実際には不要なフラグメンテーションを実行することで、本来実行する必要のないフラグメンテーションベースの攻撃ベクターが許可されてしまう。
不幸なことに、既に RFC6946 を実装しているノードでさえ、IPv6アトミックフラグメントが生成された結果、DoS攻撃にさらされる。ホストAがホストBと通信し、RFC7872 で解説されているように extension header（フラグメンテーションを含む）付きのIPv6パケットを全てドロップするように設定されており、ホストA – B間の中間ノードフィルタのいくつかでフラグメントが起きる状況を考える。
攻撃者が細工したICMPv6 PTBエラーメッセージをホストBに送った場合、MTUが1280より小さい値に設定されていると、 RFC2460 に定められているように、その瞬間IPv6アトミックフラグメントが発生する。
ホストBは（ICMPv6 PTBエラーメッセージを受信したレスポンスとして）IPv6アトミックフラグメントの送信を開始するが、事前に extension header 付きのIPv6ヘッダはホストA – B間ではドロップするように設定されているため、それらのパケットはドロップされる。
従って、この状況はDoS攻撃シナリオを実現する結果となる。別のシナリオでは、2つのBGPピアがIPv6トランスポートを実行していて、ACLでIPv6フラグメントを（コントロールプレーン攻撃を避けるため）ドロップするように指定している状況を考える。
前述のBGPピアが「IPv6フラグメントをドロップするが、ICMPv6 PTBエラーメッセージを受け取ることを望む」場合、攻撃者はMTUサイズを1280バイト未満に設定したICMPv6 PTBエラーメッセージを単純に送りつけることで、対応するピアセッションに容易に攻撃ができてしまう。
一度攻撃パケットが送られると、前述のルータは自ら、本来の自分宛てのトラフィックをドロップするようになってしまう。
この件については RFC8021 でより詳細な説明がなされてるんですが、そちらでは結論として
- IPv6アトミックフラグメントは廃止すべき
- IPv4/IPv6トランスレータは、MTUが1280バイト未満だというICMPv6 PTBエラーメッセージを生成しないようにすべき
- MTUサイズが1280バイト未満であることを報告するICMPv6 PTBエラーメッセージ自体がもはや不要であり、IPv6ノードはそのようなエラーを受信しても無視すべき
といったことが書かれてます。Informational RFCとはいえこういう文書が出るってことは、それなりに影響でかそうな感じしますね。