CVE-2015-7547: Critical Vulnerability in glibc getaddrinfo (7ページ目)

「iptables/ip6tables で制限を掛けようとしている方もおられますが、～TCPは MSSでぶった切ってるだけなので、パケット長で引っ掛けようとしても、マッチしませんでした」ワリと広まってる誤対策なので重要な話だなあ twitter.com/kunitake/statu…

2016-02-19 12:47:02

【自分用メモ】CVE-2015-7547のISCの製品（BIND/ISC DHCP/Kea）への影響。// A few words about the glibc vulnerability, CVE-2015-7547 isc.org/blogs/a-few-wo…

2016-02-19 15:04:05

（承前）抄訳：BIND：namedはgetaddrinfo()を使わない。digやdelvではgetaddrinfo()を使うのでglibcの更新を強く推奨。

2016-02-19 15:16:37

（承前）ISC DHCP：いくつかの状況でgetaddrinfo()を使う。DHCPオペレーターに対するリスクは高くないと考えるが、速やかなglibcの更新を強く推奨。

2016-02-19 15:16:52

（承前）Kea：KeaのDHCPサーバーはgetaddrinfo()を使わない。ソースと共に配布されたユニットテストではgetaddrinfo()を使う。システムの他のコンポーネントのため、速やかなglibcの更新を強く推奨するが、Keaそのものにはリスクはない。

2016-02-19 15:17:36

Toshifumi Sakaguchi @siskrn

F5の機器(BIG-IP LTMなど)は、最新バージョン(12.0.0)のみ影響あり。CVE-2015-7547 support.f5.com/kb/en-us/solut…

2016-02-19 15:20:51

IIJ-SECT @IIJSECT

IIJ Security Diary: CVE-2015-7547 glibcにおけるgetaddrinfoの脆弱性について sect.iij.ad.jp/d/2016/02/1971… @IIJSECT

2016-02-19 18:12:20

話題になっているglibcの脆弱性について、その脆弱性が発現するメカニズムを調査した結果を公開しました。また、回避策についても検討しています。 CVE-2015-7547 glibcにおけるgetaddrinfoの脆弱性について sect.iij.ad.jp/d/2016/02/1971…

2016-02-19 18:18:24

続)公開されているPoCでは、攻撃に使用されるパケットがDNSのパケットとして不正な形になっていますが、正しい形のDNSパケットでも脆弱性が発現します。このため、PoCで生成されたパケットを不正な形式であることを理由にフィルタできたとしても、それは脆弱性の回避になっていません。

2016-02-19 18:27:08

問題を発見した Red Hat の提供する access.redhat.com/articles/21614… の FAQ 2. Can a trusted recursive DNS resolver ～と異なる結論になってるのが気になるなあ twitter.com/IIJ_doumae/sta…

2016-02-19 18:30:02

また、信頼できるキャッシュサーバを利用していても、キャッシュサーバとの間が信頼できない場合、MITMやsrc spoofによって攻撃パケットを送り込むめる可能性があります。信頼できるキャッシュサーバと"信頼できるネットワークで通信している場合"のみ、回避策となり得ます。

2016-02-19 18:31:36

以上の調査は、IIJのセキュリティコーディネーションチームIIJ-SECTによって行われました。 IIJ-SECTのblogに詳細があります。 CVE-2015-7547 glibcにおけるgetaddrinfoの脆弱性について sect.iij.ad.jp/d/2016/02/1971…

2016-02-19 18:33:57

.@n_soda Mitigationの項目にある、a trusted recursive resolver on a trusted networkのことだと理解しました。つまり、＊影響軽減策としては＊機能するけど、所詮は軽減しかできないと。

2016-02-19 19:14:44

@OrangeMorishita そこは「which limits the size of ～」と続いているので、サイズ制限できるキャッシュサーバーがあれば…という文章ですよね。IIJのレポートだと、信頼できるサーバーがあり経路も安全ならTCP経由の攻撃は成立しないとあるような

2016-02-19 19:23:35

@n_soda ううむ、確かに。そこは中の人に直接確認するのがよさそうです。

2016-02-19 19:24:19

@OrangeMorishita IIJの人の方がRed Hatよりも深く考えてる可能性と、Red Hatの人がIIJの人の気づいてない攻撃ベクターを知ってる可能性の、両方があるんですよねえ…

2016-02-19 19:25:48

Mamoru Saito @msaitotypeR

@OrangeMorishita @n_soda 実は同じことを云っているつもりです。redhatは一般論としての文章であって、IIJ-SECT blogは限定的な理想的な条件(bind、キャッシュがlocalで動いてる)で全部つぶせるケースがあるよという主張です。

2016-02-19 23:56:39

.@msaitotypeR @n_soda ご説明ありがとうございます。BINDだとminimal responsesオプションを入れると緩和できるかもしれないとか、条件面をいくつか妄想しつつあります。

2016-02-20 00:01:25

Toshifumi Sakaguchi @siskrn

#Ghost2.0 vs #BigDNS

2016-02-20 00:22:31

【自分用メモ】glibcのEDNS0のペイロードサイズは1024だと。。// どさにっき IoT ～2016年2月中旬～ ■ CVE-2015-7547 ya.maya.st/d/201602b.html…

2016-02-20 10:26:08

・・・で、これですが、どのglibc・どのLinuxディストリビューションもそうなのかが確認できなかったので安全側に倒しました。

2016-02-20 10:27:37

【自分用メモ】VMware KB: VMware Response to CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow kb.vmware.com/selfservice/mi…

2016-02-20 10:45:34