続: BIND9 脆弱性: Dynamic Update DoS

いろいろためして、本脆弱性を受ける設定がわかった、、気がする今日この頃。

マスターゾーンファイルを1つ以上もっていれば、DDNSの設定有無、キャッシュサーバ、権威サーバの有無にかかわらず、BINDをクラッシュできる。

named.conf で type master でゾーンファイルをもっていると、アウト～。

例えば、

1. 権威サーバを想定

zone "foo.bar." in {
type master; ←　アウト～
file "foo.bar.zone";
};

[root@arizona ~]# ./foo.bar_sleep_tight_bind9.pl

arizona named[2779]: db.c:649: REQUIRE(type != ((dns_rdatatype_t)dns_rdatatype_any)) failed
arizona named[2779]: exiting (due to assertion failure)


2. 権威 or キャッシュサーバを想定

権威サーバでもキャッシュサーバでも localhost のゾーンを作っている
場合は多いだろうから。

zone "localhost" {
type master;　←　アウト～
file "local.zone";
};

[root@arizona ~]# ./localhost_sleep_tight_bind9.pl

arizona named[2794]: db.c:649: REQUIRE(type != ((dns_rdatatype_t)dns_rdatatype_any)) failed
arizona named[2794]: exiting (due to assertion failure)

3. 権威 or キャッシュサーバを想定

zone "0.0.127.in-addr.arpa" {
type master;　←　アウト～
file "local.ptr";
};

[root@arizona ~]# ./ptr.localhost_sleep_tight_bind9.pl

arizona named[2798]: db.c:649: REQUIRE(type != ((dns_rdatatype_t)dns_rdatatype_any)) failed
arizona named[2798]: exiting (due to assertion failure)

4. DDNS ( allow-update ) の設定ある場合でもアウト～

zone "foo.bar." in {
type master;　←　アウト～
file "foo.bar.zone";
allow-update { key DDNS; };
};

key DDNS {
algorithm HMAC-MD5;
secret　"Xmmnl6BpW/BdLepsuCEoSAx7EOHRAcK8sIZQwbM+9jlRNtUul8g0yfTl+j34IZqqMg2fYT0zkb5fzJzP6n86jQ==";
};

"クラッシュさせるDDNSクエリ"の secret キーの文字列が named.conf のそれと違っていてもnamedをクラッシュできるー。

[root@arizona ~]# ./foo.bar_sleep_tight_bind9.pl

arizona named[2804]: db.c:649: REQUIRE(type != ((dns_rdatatype_t)dns_rdatatype_any)) failed
arizona named[2804]: exiting (due to assertion failure)

5. もちろんこれもアウト～

zone "0.168.192.in-addr.arpa." in {
type master;
file "0.168.192.in-addr.arpa.zone";
allow-update { key DDNS; };
};

[root@arizona ~]# ./ptr.foo.bar_sleep_tight_bind9.pl

arizona named[2811]: db.c:649: REQUIRE(type != ((dns_rdatatype_t)dns_rdatatype_any)) failed
arizona named[2811]: exiting (due to assertion failure)

ということで、again !!
type master でマスターゾーンが一つ以上存在すれば、named をクラッシュさせることができる～。

テストしたところ、100%クラッシュできた～。
コアファイルもできたー

[root@arizona ~]# ls /var/named/*core*
/var/named/core.2650 /var/named/core.2779 /var/named/core.2804
/var/named/core.2660 /var/named/core.2794 /var/named/core.2811
/var/named/core.2668 /var/named/core.2798

下記のソースコードを修正したみたい～。

bind-version/bin/named/update.c

[root@arizona ~]# diff /usr/local/src/bind-9.6.1/bin/named/update.c /usr/local/src/bind-9.6.1-P1/bin/named/update.c
18c18
< /* $Id: update.c,v 1.151.12.5 2009/04/30 07:03:37 marka Exp $ */
---
> /* $Id: update.c,v 1.151.12.5.12.1 2009/07/28 14:18:08 marka Exp $ */
982c982,986
< else
---
> else if (type == dns_rdatatype_any) {
> dns_db_detachnode(db, &node);
> dns_diff_clear(&trash);
> return (DNS_R_NXRRSET);
> } else

んで、修正バージョン( 9.6.1-P1 ) だと大丈夫～。

[root@arizona ~]# named -v
BIND 9.6.1-P1

[root@arizona ~]# ./ptr.localhost_sleep_tight_bind9.pl
[root@arizona ~]# ./localhost_sleep_tight_bind9.pl
[root@arizona ~]# ./foo.bar_sleep_tight_bind9.pl
[root@arizona ~]# ./ptr.foo.bar_sleep_tight_bind9.pl

update unsuccessful というログがでるだけ。

arizona named[12059]: client 127.0.0.1#42951: updating zone 'localhost/IN': update unsuccessful: localhost/ANY: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)
arizona named[12059]: client 127.0.0.1#34891: updating zone '0.0.127.in-addr.arpa/IN': update unsuccessful: 1.0.0.127.in-addr.arpa/ANY: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)
arizona named[12059]: client 127.0.0.1#58885: updating zone 'foo.bar/IN': update unsuccessful: foo.bar/ANY: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)
arizona named[12059]: client 127.0.0.1#40956: updating zone '0.168.192.in-addr.arpa/IN': update unsuccessful: 1.0.168.192.in-addr.arpa/ANY: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)

[root@arizona ~]# rndc status
version: 9.6.1-P1
number of zones: 16
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running
[root@arizona ~]#

ちゃんといきてるー。

[root@arizona ~]# dig @127.1 www.foo.bar. +norec

; <<>> DiG 9.6.1-P1 <<>> @127.1 www.foo.bar. +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31832
;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.foo.bar. IN A

;; ANSWER SECTION:
www.foo.bar. 3600 IN A 192.168.0.3


[root@arizona ~]# dig @127.1 www.google.com.

; <<>> DiG 9.6.1-P1 <<>> @127.1 www.google.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41114
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 6, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com. IN A

;; ANSWER SECTION:
www.google.com. 604800 IN CNAME www.l.google.com.
www.l.google.com. 300 IN A 72.14.203.103


ということで、パッチをあてるしかなさそうな感じ。
ワークアラウンドなしっていってるしなー。

Workarounds:
None.

(Some sites may have firewalls that can be configured with packet filtering techniques to prevent nsupdate messages from reaching their nameservers.)

iptables で、updateのフラグがついているクエリ落とすっての記載されていたけど、upgradeしたほうがよさそう。。

As a hint for other sysadmins:

For the time until a fixed debian package is available, this iptables rule
should filter all dnsupdate packets, thus mitigating the attack:

| iptables -A INPUT -p udp --dport 53 -j DROP -m u32 --u32 '30>>27&0xF=5'

Works for me, but no guaranty. I have added a second rule which logs
said dnsupdate packets and i already got several such packets from the
outside world, so the exploit is clearly in active use and the least you
can do is to try the iptables rule.

the exploit is clearly in active use　ってコメントが気になる～。

ジミヘンいいなー。Zep も好きだけど、ジミヘンも好きだー。

Freedom, freedom
To live
Freedom, freedom
So I can give

ジミヘン、、難しくてギターひけん。。。