$30 off During Our Annual Pro Sale. View Details »

BIND Memory leak Vulnerability and Root KSK Rollover

BIND Memory leak Vulnerability and Root KSK Rollover

Toshifumi Sakaguchi

April 23, 2019
Tweet

More Decks by Toshifumi Sakaguchi

Other Decks in Technology

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より報告

    別の脆弱性の対応に問題があり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
  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