Slide 1

Slide 1 text

BIND メモリリーク脆弱性とRoot KSK Rollover 2019/04/23 JANOG 43 -> DNS温泉番外編 -> ssmjp Toshifumi Sakaguchi 1

Slide 2

Slide 2 text

Agenda 2019/02/22に公開されたBIND脆弱性CVE-2018-5744と、それに関連する事を説明します ⾃⼰紹介 BIND脆弱性の概要 Root KSK Rollover The Signaling Trust Ancker Knowledge BIND脆弱性の原因とその対応 Root KSK Rolloverの振り返り まとめ 2

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

脆弱性の対象 権威サーバ、フルリゾルバのいずれでも対象 対象のバージョン 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

Slide 6

Slide 6 text

攻撃容易性 脆弱性の発⾒時は、おそらくExploitはないはず 運⽤環境で発⽣していない Fuzzing環境で発⾒ 検証コードの作成は⾮常に容易 Release Notesの説明で⼗分 コーディングも容易 悪⽤は困難︖ 数個のDNSクエリで、サーバ上のメモリを使い切ることはない 例えば1GBのメモリをリークさせるためには、合計1GB以上のクエリが必要 サーバのメモリに空きがあれば、それを埋めるための時間と帯域が必要 6

Slide 7

Slide 7 text

対策 回避策はなし Workaround: None. ある新機能が原因だが無効化できない BINDのバージョンアップが必要 7

Slide 8

Slide 8 text

Key Tag Optionとは 2016年10⽉から始まった、Root KSK Rolloverの中で導⼊された Signaling Trust Anchor Knowledge の中で定義されたEDNS拡張 8

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

Signaling Trust Anchor Knowledge 以下の機能の実装が必要 Validator側でKey Tagを送信する機能 権威(Root)サーバでKey Tagを観測する機能 12

Slide 13

Slide 13 text

脆弱性の原因 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

Slide 14

Slide 14 text

脆弱性の対応の履歴 参考⽂献 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

Slide 15

Slide 15 text

2019/01/23 更新後のBINDの不具合修正? Master BranchのCHANGESに"placeholder"追加 2019/01/29 更新後のBINDの不具合修正? Master BranchのCHANGESに"placeholder"追加 2019/02/06 ISCより報告 別の脆弱性の対応に問題があり2⽉中旬にリリース予定と連絡 2019/02/07 BIND 9.11.5-P4/9.12.3-P4 ASNへ公開? https://ftp.isc.org/isc/bind9/private の更新 2019/02/22 脆弱性公開 15

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Root KSK Rollover の振り返り Root KSK Rolloverの前後のKey Tagの観測状況 APRICOT 2019 KSK Rollover 2015-2019(https://www.slideshare.net/apnic/ksk-rollover-20152019) 17

Slide 18

Slide 18 text

Root KSK Rollover の振り返り APRICOT KSK Rollover 2015-2019(https://www.slideshare.net/apnic/ksk-rollover-20152019) 18

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

まとめ Root KSK Rolloverに関連したBINDの脆弱性 Key Tag Optionを実装しなければ避けることができた脆弱性 本件の脆弱性対応はあまりよくなかった 今回のRoot KSK Rolloverにおいて、結果としてSignaling Trust Anchor Knowledgeは参考 にならなかった 20