脆弱性の内容、各ディストリビューションからのアップデートは各テック系サイトのニュースをご参照ください。
さて、大人の事情によりすぐに直せないよーという場合の緩和策(あくまでも緩和策です)として [PATCH] CVE-2015-7547 --- glibc getaddrinfo() stack-based buffer overflow では以下のものが挙げられてます:
UDP
- 513 バイト以上の UDP DNS パケットを firewall で落とす
- (略)
- `options edns0` を /etc/resolv.conf で使わない。EDNS0 は 512 バイトより大きいレスポンスを許可するので、正当な DNS レスポンスでも overflow を発生させることが出来てしまいます
- (略)
TCP
- DNS リプライを 1024 バイトまでに制限する
read() のバッファサイズと発行回数の都合で、1 packet が 1024 バイトまでならバッファがあふれる前に処理できる可能性が高い? でも、「パケット」については言及されてない。
有効でない緩和策
ちなみに、意味のない緩和策として
- `options single-request` は内部でのバッファー管理方法に変わりはないので意味なし。
- `options single-request-reopen` も 1. と同様。
- IPv6 を無効にしても、(AF_UNSPEC が使われていると)AAAA クエリを投げること自体は止められない。
- だから `sysctl -w net.ipv6.conf.all.disable_ipv6=1` は意味ない
- ローカル、または中間のリゾルバで IPv6 をブロックしてもダメ。クエリを並行して投げるところがバッファ管理の問題を引き起こしてるからです。exploit パケット自体は A への応答でも AAAA への応答でもありえる。
が挙げられてます。
その他
不正でない DNS レスポンスで exploit 可能だし、多分中間に cache サーバーがあってもその先まで侵入可能っぽいよ
ってことも書いてあるんで、単にDNSリレー/キャッシュを守るだけじゃクライアントを守れないっぽい (dnsmasq ならレスポンスサイズを制限できる)。
0 件のコメント:
コメントを投稿