(dnsmasq への追記あり) CVE-2015-7547 glibcのgetaddrinfo に stack buffer overflow の脆弱性[Linux]

このエントリーをはてなブックマークに追加

2016-02-17

久々？に大きな脆弱性が出ました。glibc2.9 以降で発現する脆弱性です。

詳細は

CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow
https://googleonlinesecurity.blogspot.jp/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html

に詳しいです。主な影響を受けるディストリビューションは下記の通り

Distribution Vuluneable
RHEL5/CentOS5 受けない
RHEL6/CentOS6 受ける
RHEL7/CentOS7 受ける
Debian squeeze 受ける
Debian wheezy 受ける
Debian jessie 受ける

この情報は下記から

CVE-2015-7547: Critical Vulnerability in glibc getaddrinfo
https://isc.sans.edu/forums/diary/CVE20157547+Critical+Vulnerability+in+glibc+getaddrinfo/20737/

getaddrinfo() を使ってる場合に、影響を受ける可能性があります。

すでに PoC は公開されていています。

https://github.com/fjserna/CVE-2015-7547

ここに公開されている CVE-2015-7547-proc.py とかを root 権限付きで実行すると、この手の buffer overflow を引き起こすパケットを返してくる DNSキャッシュサーバもどきになってくれます。

これをローカルで動かした状態で /etc/resolv.conf に

nameserver 127.0.0.1


とすると、

$ ssh www.example.jp
Segmentation fault


という感じで、落ちてくれます。

ただ、普通のDNSキャッシュサーバは、この手の malformed packet は、リゾルバには返さず SERVFAIL が返ります。
なので、影響を受ける Linux が参照している DNSキャッシュサーバが、自分が管理しているunbound だったり bind だったりする場合には、直近影響を受けないといっていいと思います（追記：後述しますが、残念ながらこれだけでは攻撃の可能性を完全に排除できないそうです）。aws では影響がないとのコメントが出されています。

CVE-2015-7547 Advisory
https://aws.amazon.com/jp/security/security-bulletins/cve-2015-7547-advisory/

EC2 customers using the AWS DNS infrastructure are unaffected and don’t need to take any action.


とは言いながらも、脆弱性は残っているので、ちゃんとアップデートしておきましょう。アップデート後は、古いライブラリを読み込んだままだったということがないように、サーバを reboot しておくといいと思います。

# lsof -d DEL


して、かたっぱしから該当する daemon を再起動するってのでもいいかもしれませんが。

ちょっと不安なのは





このあたりですかね。環境によっては、偽造パケットというかたちで差し込まれたりする可能性もあるので、注意が必要です。
そういった不安がある環境で、どうしてもすぐにはアップデートできないなら dnsmasq を仕込んでこいつにリゾルバを向けて、応答を受けてもらいましょう。これも有効な workaround となります(追記：後述しますが、どうもこれも怪しそうです。workaround探している間にアップデートしてしまいましょう。）

ps. どうでもいいですが、unbound の do-not-query-localhost が default で yes になっていることに気づかずに(というか、そもそもそういう設定があることに気づかずに）、なかなかテストができずにハマりました……

追記その１: 2016/02/18 02:17 JST



との情報が。

https://access.redhat.com/articles/2161461

には、下記のような記載があります。

2. Can a trusted DNS resolver protect against this issue?
A trusted resolver, in a default, protocol-compliant configuration,
cannot mitigate this issue because potential exploits could involve
syntactically well-formed DNS responses.


つまり、DNSキャッシュサーバでは仕様に沿ってないパケットは SERVFAIL で落とせるけど、仕様に沿ったパケットはリゾルバに返してしまうので、そういったパケットを通じて攻撃可能だということのようです。

なので、Google Online Security Blog の内容も加味してまとめると

(1) DNSキャッシュサーバでは、完全には攻撃を防げない
(2) getaddrinfo() の脆弱性を付くには 2048バイトを越えるレスポンスである必要がある
(3) dnsmasq のように(追記：どうやら後述するように、dnsmasqでは十分な制限を掛けられない可能性があります）、レスポンス長に制限(2048バイトを越えさせない）が掛けられるものだけを使えば緩和策として使える

ということのようです。aws が自身のDNSキャッシュサーバを利用している限りにおいては影響がないといっているのは、スタブリゾルバへの返信が2048バイトを越えないようにしているぜ！ということなのかもしれません。

ともあれ、ここに至っては下手に回避策を探るより、素直にパッケージをアップデートしてサーバを再起動しておいた方が無難ですね……

追記その２: 2016/02/18 15:50 JST

dnsmasq が緩和策として使えるとありますが、これはおそらく 2.73 から導入された

/* src/config.h */
#define SAFE_PKTSZ 1280 /* "go anywhere" UDP packet size */


これを指しているんだと思います。ハードコーディングで 1280バイトに制限されているので、攻撃パケットは届かなくなります。

On CVE-2015-7547 - glibc/getaddrinfo
http://lists.ipfire.org/pipermail/development/2016-February/001545.html

ちなみに、最新の dnsmasq-2.75で実行するとこんな感じです(+ignore をつけることで、TCPのフォールバックを起こさないようにしています）

$ dig +dnssec hiv dnskey +ignore

; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.2 <<>> +dnssec hiv dnskey +ignore
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25086
;; flags: qr tc rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;hiv. IN DNSKEY

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: 実行した日付
;; MSG SIZE rcvd: 32


ですが、TCPにフォールバックさせると

$ dig +dnssec hiv dnskey +short
;; Truncated, retrying in TCP mode.
256 3 7 AwEAAaaV7VJUrPL0rN5/eMz3l4v9ur0xPYz0+DWpioxK7hqSmsV18oGW Zq3mHfKH8fSAkaMIlmWvqT64m60hthhdW5YZC3GQ0HzI8mwAebEkiDuc WjKME3Lk3ktC0mhlTMWjsF8MwAF2cE+1CczLHeHWrgkR2Y5qPgd14fwo 474g2Nuf
257 3 7 AwEAAYM1Sl/orr8SqlvM6ShxKBdJMSOeD7HcTFP+TTDpVJpSHBhmAsMb 30JtMRo68dsG4rIBBpc69718m0j1l8zK1uNxoJx5UkfNWG0GoOp6EKur LkLTk3luzDNmj3jrgS4oz6ztb6QYsj0hnKgMA7HW335Cb14J+vSATDpj 79cnMa4h0Ik7pIufPmAYFmQWBZeOr+99QOdzqP5zX9j5nyOEbGv82+xD 4bcFstecZ6In8WdscwoglhXdPCY1ZEtbEGiIS21ENx+o2CWAaFHpiIua sjbYVQd6+HzNSBLagDx7+aRHqDCqux6ezHGw3wbVxkHB7OP1sAcRTJX+ 85rOjmXCJss=
257 3 7 AwEAAY/iJlahfRMvTBe89WI1KnkyOzhOapyM790ybtDXYd0Uf2C7T2VN DyMabc8mUaZA36F6aUpMmQW21SzoxtrJgzvJFgrxuhkU0reyczS/bOx7 lgH10VXdaFj2mDVeXJALl1P6JQ3gwMjD6O4+z/su2C6vrtIrSfexeI4o HWZxdMQ2Y123lq1nz1ZgIbJSWJOQbaFf3cZm1qETK4R8yEATgCfnZCQP rxb424FNsR8KgNsVNUevXDgbbzwVYY3y4dMqsDXMXj2pekJgzY2h2dAZ h50NvjXbWOcbcsurv5qEiY6lZ2F59KN6vn9zYiICE5c7BUbI6MgskRQ7 Ny53Oj4pMdk=
256 3 7 AwEAAa6bxHsMEnf15WewlIH4t8rtq2kFfk7XsOp78U+wRHfE5ycPx7WS hqNQ8lpcAQyEtob0GERdaaSA56pDVhBUt7FWgS0UKejhe/NUBEFXZ0J0 X2KzH25BNO0VFDutRbk9lbcv3jO9Is//mxRdFm3qQbdSXjyh7AGRWs/9 Bi8EhXBcX/bFnfdQDw6K5dsJTCzF5cp2+dUQ79ZAGlVacURkvvIPXd8N TJfuOgdNArXKbnEvUATuxwPM3rtnjWNTMIl5ONk5kn24eCpjyfzrOVVb KxvvhetNN9znv4xlZIQaLw+ybPfz4BgbKKwDjQr62H4E0fSyqRCBONaa 9sN+5TwV/i8=
256 3 7 AwEAAW+TjE1zmCMfjLHfwz0OlPh4daGbN50xIEFsXRmlPNQN8pVJHIpf 7NMooeg9yUj607O3cMN/T2I8TL2cjqOL+eLvepNc3Fp+J2ohlEI6tHmL C5mTZkU1xGD7myygnX/XelU7eAaHNdIkghRuzo3KSg0zvCBSeslCON4H 0xDYWYEr
257 3 7 AwEAAbwvxlNQlQoVmdOKIA6Mb3EpOCXFZicDnNEAkAz3I7xHmOm3kCbf Z/w2vY9VMiTLBafXqjFVgxH33+fKlOKL0gR5iwTLC6W3boH8up1icAZp X2wMcYhS2Mauj/MGBUtQokXoBuM758K7+rq2r3Or9KX5fHYbk6bNi8cH 6ThCWcmXEptAb1vLjYaIyJtj6IYjnkt0LOrUUOCDrj+oOkYXXvUX1ZP3 kVvS677Ch00jjDQuooTQ+l/AgI2cU7wIl2peTu/ZnaFzFVsvzD2vTD0d g0lzwMCa78smO/WLJpTtmptbPnK8ct1QdWbquALlrQ51bOOrjVaU32KU uAws7EgLnnE=
DNSKEY 7 1 86400 20160319061524 20160218061524 43515 hiv. odss/n3ue7l0Omba5suryXMZoRZiLZ9Qhq6Nv/az/y4HvrSqpRiB69XD /lVQGjKf44iNFtoxaL+K8qZxvDvHrWwVGpvGZjG8utB9Qhs0kaUUKnkT fbz1PamWT5BSvG6gSB2JSsN2BKlwBSuo8yQfgXNSNjO3Hf+mEVWzOB5i z6GRRohA9YjwdsRV3ZHqQMVhzCN3wTEH5fNg+cVunr41Kenx/glMOyjc nJseFXEiZJo3J3ejzerswYWMUcqjf62Yo81Kv47SLVa6pHHuUjA58Fhp z2btvLHy77YKOViYMzBIuiNluShjcnWJTWkeUGGZ4hpYE8dYYq4529VE wLLRMw==
DNSKEY 7 1 86400 20160319061524 20160218061524 56208 hiv. JtWLdWOmsDvis1P4kZad+CafHR/bLnY1u4vMe4ytqmOrvftqGidv3CYw n7cff13fusjBdnuoHpT/JP0NIpPg/W6gkNyF1iwLCAzFwFCYjb8mtOIc bWOYuJTdtY/aO0XngVr0QDTOLEUfns5NcXsqu82Ne40VOAhm+zo08CeY V66ex21CMgt33scYT9c8HzCloDn14ltAeG3aZcb9C7wCBOUnmRYvFDZZ t1eLsGBER+2pScQlhXTsx/+gmDphCULzvjoRUCzWw3gQ4+Bfk3AiLIqn aaSIJSLRhr+5Ak0XoVKCtYFaVhk9fyd2U7YGAUlF0pbng+WMGbe1KY2k QX4gGw==


のように、普通に制限しているはずの1280バイトを越えるレスポンスを受け取ってしまっています。なので、緩和策としては不十分じゃないでしょうか？(間違っていがら指摘願います。ちなみにTCPなので関係はないんですが念のため edns-packet-max も設定してみましたが、ダメでした）
もちろん、UDP／TCPともに制限が掛けられるものをお使いならばそれでいいとは思いますが、そうでなければ workaround は諦めて、可及的速やかに該当パッケージをアップデートすることをお勧めします。

あと、iptables/ip6tables で制限を掛けようとしている方もおられますが、UDPはいいんですが TCPは MSSでぶった切ってるだけなので、パケット長で引っ掛けようとしても、マッチしませんでした（これは私も気付かず、詳しい方に教えていただきました）。なのでこれも対応としては不十分だと思われます。

ということで、重ねての結論ですが、さっさとアップデートしましょう……

追記その３: 2016/02/18 18:15 JST

bind や unbound の max-udp-size による制限も、オプション名から考えても、UDP限定です。残念ながら、これ自体は実際に検証しませんでしたが、TCP には無力のはずです。改めて RedHat さんの

Critical security flaw: glibc stack-based buffer overflow in getaddrinfo() (CVE-2015-7547)
https://access.redhat.com/articles/2161461

を読むと

The TCP-based vector could be mitigated by a trusted recursive resolver
on a trusted network which limits the size of individual DNS responses to
1023 bytes and below. However, such a capability is not common in DNS resolver
implementations because it breaks the DNS protocol. (The buffer size
configuration option offered by most resolvers only applies to UDP, not TCP.)
Rejecting AAAA responses, without also limiting the size of A responses, does
not mitigate the vulnerability.


とあるように、やはり TCPへの対策にはならないよと書いてありました。

追記その４： dnsmasq に関する dig のコピペミスがあったので、直しました。

追記その５： 2016/02/19 19:46 JST

IIJさんより詳細な解説情報が出てきました。流石IIJさんですね！

CVE-2015-7547 glibcにおけるgetaddrinfoの脆弱性について
https://sect.iij.ad.jp/d/2016/02/197129.html





という懸念も確かに気になるところですが、IIJさんの考察による結論にはすごく納得がいくところです。

悩ましいところですが、どっちが正しくても glibc を上げとけば問題ないので、やっぱり上げておくことをお勧めしたいです。

固定リンク コメント
このエントリーをはてなブックマークに追加
IPv4/IPv6 meter
検索キーワードは複数指定できます
ChangeLogを検索
Google
Web www.kunitake.org
思ったより安い……時もある、Amazon

カテゴリ