二週間ほど前に恐ろしい毒入れ手法が成立しうることに気づいて、どうやって公表したらよいか悩やんだのだけれど、何と Herzberg と Shulman の論文を読み返したところアバウトながらしっかり書いてあったので躊躇することなく解説することにした。なぜ私はこれを読み流してしまっていたのか。どうしてこれを誰も騒ぎにしていないのだろうか。
DO bit を常に on にしろという RFC 4035 の傲慢な要請は修正されるべきだと思う。そして RFC 2308 という酷い RFC (私なら査読通さない) も SOA に付随する NS を許さないよう書き直されるべきだと思う。(私に IETF に行けというのは無し)
以下、第一フラグメント便乗攻撃の原論文 Fragmentation Considered Poisonous の II 章の C. Circumventing the Cache が示唆していると思われる攻撃手法の解説 (11/4 追記: こっちの論文のほうが詳しい。同じ内容かと思ってちゃんと読んでいなかった。迂闊。https://arxiv.org/pdf/1205.4011.pdf 4.1.1 Injecting NS RR to NSEC3 Response)
検証用のゾーンを作成したのでご利用ください。
dig hoge.sub.mufj.jp txt ; dig fuga.sub.mufj.jp txt
などと二度 (負荷分散されている環境では多数回) 繰り返して
"Your_cache_server_is_vulnerable."
と出たら使用中のキャッシュサーバは第一フラグメント便乗攻撃への耐性が低いと考えられます。ただし EDNS0 への対応等は別途検査が必要です。
(Unbound で検証済/harden-referral-path:yes にしないと危険 (追記: 1.8.2 で対策されました))
要するに DNSSSEC 署名しているドメインは、どうぞ未検証のキャッシュに毒入れしてくださいと言っているようなものである。そして検証もしないのに DO bit を常に立てているキャッシュサーバはマヌケである。(パッチが提供されるべきであろう)
(「DNSSEC はなぜダメなのか」もどうぞ)
11/5 追記: シャルマンらの論文 5 Conclusions and Defenses の以下の指摘はとても重大な指摘だと思う。大きな議論になっていないのが不思議だ。
We want to caution against drawing the conclusion that DNSSEC should not be used. In fact, the best defense is to apply DNSSEC correctly in all resolvers and domains (without using NSEC3 opt-out); this will certainly prevent many of our poisoning attacks, and even defend against more powerful Man-in-the-Middle adversaries. However, incremental DNSSEC deployment is vulnerable to our cache poisoning attacks, and complete adoption of DNSSEC may take considerable time, since it depends on adoption by both name server and resolver.
追記: Let's Encrypt は EDNS バッファサイズを 512 にしたとアナウンスしています。正解ですね。
p.s.
この件でも思うのだが脆弱性はぼやかさずはっきりと解説されるべきだろう。悪いやつらだけが高いモティベーションで攻撃方法にたどり着き、守備側は何が危ないかも理解できないまま放置されることになる。
Copyright by T.Suzuki
Before...
■ tm [additional sectionのすり替えが可能だと書きましたが、 それがキャッシュを上書きして、毒となるかど..]
■ sk [今までの狼少年的な騒ぎ方が問題だったのではないでしょうか？]
■ tm [フラグメント化されるくらい大きなAnswerあり返答で、Authority Sectionを置き換える攻撃を検討して..]