BIND Memory leak Vulnerability and Root KSK Rollover

Transcript

1. BIND メモリリーク脆弱性とRoot KSK Rollover 2019/04/23 JANOG 43 -> DNS温泉番外編 -> ssmjp Toshifumi Sakaguchi 1
2. Agenda 2019/02/22に公開されたBIND脆弱性CVE-2018-5744と、それに関連する事を説明します ⾃⼰紹介 BIND脆弱性の概要 Root KSK Rollover The Signaling Trust Ancker Knowledge BIND脆弱性の原因とその対応 Root KSK Rolloverの振り返り まとめ 2
3. Who am I ? 坂⼝俊⽂/Toshifumi Sakaguchi Twitter: @siskrn GitHub: https://github.com/sischkg/ DNS Summer Day, DNSOPS.JP BoF, JANOG Interim 42.5で発表 主な実績 CVE-2015-1868, CVE-2015-5470(PowerDNS Security Advisory 2015-01) CVE-2016-2848(BIND) CVE-2017-15120(PowerDNS Security Advisory 2017-08) CVE-2018-1110(Knot Resolver) CVE-2018-14644(PowerDNS Security Advisory 2018-07) CVE-2018-5744(BIND) 3
4. BINDのメモリリークの脆弱性(CVE-2018-5744) A specially crafted packet can cause named to leak memory 複数の Key Tag Option を持つDNSクエリを受信するとメモリリーク Release Notes for BIND-9.11.5-P4 named leaked memory when processing a request with multiple Key Tag EDNS options present. Key Tag Optionの説明は後で 4
5. 脆弱性の対象 権威サーバ、フルリゾルバのいずれでも対象 対象のバージョン 9.10.7 -> 9.10.8-P1 9.11.3 -> 9.11.5-P1 9.12.0 -> 9.12.3-P1 対象Linuxディストリビューション RHEL/CentOS 7は9.9.5のため対象外 Ubuntuは18.04LTSが対象 主にISCが配布しているソースコードからインストールしている⼈が対象 5
6. 攻撃容易性 脆弱性の発⾒時は、おそらくExploitはないはず 運⽤環境で発⽣していない Fuzzing環境で発⾒ 検証コードの作成は⾮常に容易 Release Notesの説明で⼗分 コーディングも容易 悪⽤は困難︖ 数個のDNSクエリで、サーバ上のメモリを使い切ることはない 例えば1GBのメモリをリークさせるためには、合計1GB以上のクエリが必要 サーバのメモリに空きがあれば、それを埋めるための時間と帯域が必要 6
7. 対策 回避策はなし Workaround: None. ある新機能が原因だが無効化できない BINDのバージョンアップが必要 7
8. Key Tag Optionとは 2016年10⽉から始まった、Root KSK Rolloverの中で導⼊された Signaling Trust Anchor Knowledge の中で定義されたEDNS拡張 8
9. Root KSK Rollover Root Zone のKSK（ZSKを署名するための鍵)を新しいものに変更する作業 新しいKSKで署名するまえに、対応する新しいTrust AnchorをValidator(Resolver)に設定す ることが必要 新しいTrust Anchorがないと名前解決に失敗 Rollover前に、新しいTrust Anchorが設置されていることを確認したい Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) 9
10. Signaling Trust Anchor Knowledge RFC8145 Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) (https://tools.ietf.org/html/rfc8145) 新しいTrust AnchorをValidatorへ設定したかを調査するために導⼊ Validatorが使⽤しているTrust AnchorのKey Tagを、権威サーバへ通知 +------------+ +---------------------+ | 権威サーバ |<=== Key Tag(1111,2222)===| validator(resolver) | +------------+ +---------------------+ 10
11. Signaling Trust Anchor Knowledge Key Tagの通知⽅法 クエリのOPTレコードに Key Tag Option を追加 +--------------+--------------+--------------+--------------+ | optcode=14 | opt-length=4 | keytag=1111 | keytag=2222 | +--------------+--------------+--------------+--------------+ クエリのQNAMEにKey Tagを含むクエリを送信 QNAME=_ta-1111. QCLASS=IN QTYPE=NULL QNAME=_ta-1111-2222. QCLASS=IN QTYPE=NULL 11
12. Signaling Trust Anchor Knowledge 以下の機能の実装が必要 Validator側でKey Tagを送信する機能 権威(Root)サーバでKey Tagを観測する機能 12
13. 脆弱性の原因 BINDのメモリリークは、受信したKey Tagをログへ記録する機能とともに追加 (https://gitlab.isc.org/isc- projects/bind9/commit/b41c1aacbc550fa67bfa62df3114b1d668b9c8d8) 4759. [func] Add logging channel "trust-anchor-telementry" to record trust-anchor-telementry in incoming requests. Both _ta-XXXX./NULL and EDNS KEY-TAG options are logged. [RT #46124] Key Tag Optionをパースするprocess_keytagに問題 (https://gitlab.isc.org/isc-projects/bind9/blob/v9_11_5_P1/bin/named/client.c#L2110) 13
14. 脆弱性の対応の履歴 参考⽂献 BIND脆弱性が出るタイミングを⾒抜く⼒を︕ (https://dnsops.jp/bof/20161201/IW2016DNSOPS_BoF_yfujiwara.pdf) 2018/12/09 脆弱性発⾒、即ISCへ報告 2018/12/10 ISCから回答 年末にシステムを更新しない組織があるため、公開は1⽉の上・中旬の予定 2018/12/13 脆弱性修正? Master BranchのCHANGESに"placeholder"追加 2018/12/28 ISCより報告 他の脆弱性の対応もあり、公開は1⽉の後半 2019/01/15 BIND 9.11.5-P2/9.12.3-P2 ASNへ公開? https://ftp.isc.org/isc/bind9/private の更新 14
15. 2019/01/23 更新後のBINDの不具合修正? Master BranchのCHANGESに"placeholder"追加 2019/01/29 更新後のBINDの不具合修正? Master BranchのCHANGESに"placeholder"追加 2019/02/06 ISCより報告 別の脆弱性の対応に問題があり２⽉中旬にリリース予定と連絡 2019/02/07 BIND 9.11.5-P4/9.12.3-P4 ASNへ公開? https://ftp.isc.org/isc/bind9/private の更新 2019/02/22 脆弱性公開 15
16. Signaling Trust Anchor Knowledgeの実装状況(Validator) Open SourceのDNS ResolverのRFC 8145の実装状況 BIND 9.9.10, 9.10.5, 9.11.0 (2016/10/04, default on) Unbound 1.6.4(2017/06/27,default off), Unbound 1.6.7(2017/10/10, default on) PowerDNS Recursor未実装 Knot Resolver 1.5.0(2017/11/02, default on) ほかの実装は未調査 ただし、すべてQNAMEを使⽤した実装で、Key Tag Optionは未実装 Key Tag Optionを実装する必要性は︖ 16
17. Root KSK Rollover の振り返り Root KSK Rolloverの前後のKey Tagの観測状況 APRICOT 2019 KSK Rollover 2015-2019(https://www.slideshare.net/apnic/ksk-rollover-20152019) 17
18. Root KSK Rollover の振り返り APRICOT KSK Rollover 2015-2019(https://www.slideshare.net/apnic/ksk-rollover-20152019) 18
19. Signaling Trust Anchor Knowledge による観測結果 Signaling Trust Anchor Knowledgeは新しいvalidatorのみ実装されているため、観測対象 は偏っている 間違った実装の存在(BIND) 署名検証しない設定でも、Key Tagを送信 Suppress trust-anchor-telementry queries if validation is disabled. [RT #46131] 次回 Root KSK Rollover時は役⽴つかも(個⼈の感想) 19
20. まとめ Root KSK Rolloverに関連したBINDの脆弱性 Key Tag Optionを実装しなければ避けることができた脆弱性 本件の脆弱性対応はあまりよくなかった 今回のRoot KSK Rolloverにおいて、結果としてSignaling Trust Anchor Knowledgeは参考 にならなかった 20