IPv4 転送は、KAME 派生のIPSec のインバウンド SPD を調べない

［翻訳：関谷　麻美］
2002年3月11日

国際海外情報

2002年3月20日（水） 12時00分

［翻訳：関谷　麻美］
2002年3月11日

概要
　NetBSD 1.5.2 と現行バージョン、FreeBSD 4.5 と現行バージョンそして NetBSD と FreeBSD の KAME バージョンは RFC2401 のセクション4.4.1および5.2.1（ステップ3と4）に背き、転送されるパケットのインバウンド・ポリシー・チェックに失敗する。NetBSD、FreeBSD そして KAME は既に、この問題を解決するため変更した。

　注意を払う一般的なケースは、セキュリティ・ゲートウェイだ。セキュリティ・ゲートウェイでは、機密性と整合性を提供するためにピア・ゲートウェイからのパケットは ESP であることが要求される。SG ピアが ESP を使えなかった場合、機密性は失われる。また、ローカルSG がRFC2401 に従い、インバウンド SPD チェックを行った場合、パケットは ESP を必要とすると判定され、そして落とされるだろう。しかし、現在のコードでは SPD チェックは実行されず、（改ざんされた可能性のある）パケットは SG に依存するホストにおそらく転送されるだろう。

詳細
　その不具合は、802.11 LAN のネットワーク・アクセスの制御を試みた際に、無線ホストから伝送される全トラフィックのトンネルモード ESP を必要とすることにより有線で繋がれたインターフェースと 802.11 インターフェースを持つ SG とホストのトンネルの終端で確認された。我々は、（構成エラーにより伝送された）非 ESP パケットを SG が転送したことを確認した。すなわち、これは逆の結果を伴わない状況において、セキュリティ・ポリシーに反した実際の失敗である。セキュリティ・ポリシーは、有線ネットワークおよび結果として生じるインターネット接続へのアクセス制御と 802.11 を介して機密性を確保するためにESP を要求した。当該不具合を用いて攻撃者は、インターネットにパケットを投入することができる。ただし、正しく SG が機能しているかをアウトバウンド SPD がチェックするので、パケットを受信することはない。

　src/sys/netinet/ip_input.c を調べ、そして ip_forward() のコールからコードを辿りなさい。インバウンド SPD は、このホストのパケット用のみ、そして PR_LASTHDR を伴うプロトコル用のみに実行されることに注意して頂きたい。すなわち、ソケット毎のポリシーを有効にするため、プロトコル実装までチェックを延期する。

　IPv4 のこの問題を修正するパッチは、 NetBSD の netbsd-1-5 branch および FreeBSD のRELENG_4 branch にそったごく最近の指摘に対しても対応している。ip_input.c の KAME バージョンも殆ど同じだ。それらのパッチは、おそらく十分ではない。すなわち、（IPv6 実装と協調関係にある）ip_forward 内でチェックが実行されるべきだ。全てのコードパスを考察する際、より慎重な解析が必要とされる。すなわち、我々はインバウンド SPD チェックとトンネル（例えばgif）や他の機能の対話と見なさない。特に、ソース・ルーティング・オプションを経由するパケットの転送は、間違って処理されると思われる。

他のシステム：
　FreeBSD RELENG_4 と NetBSD netbsd-1-5 は、ip6_forward の IPv6 用にこのチェックを実行すると思われる。すなわち、KAME は1999年9月1日以降、関連するコードを保持している。

　OpenBSD は、2000年9月1日の src/sys/netinet/in_input.c の改訂版1.58 よりこのチェックを開始した。

技術的詳細：
　我々は、Alice と Bob を使って簡単な構成用の詳細を提示する。Alice と Bob の二つのネットワークは、二つのSG alice-gw とSG bob-gw により接続されており、名目上そのネットワーク間の全トラフィック用にトンネルモードESP の使用を指定する。（我々はIPアドレスを隠し、関連性のないトラフィックを除去して実際の実験から得られた結果を提示する。）

10.1.1.48/28 は、Alice のネットワークで、10.1.1.64/28 は、Bob のネットワーク（両者は赤）。
10.1.1.32/28 は、Alice（.34）とBob（.35）に繋がっている黒のネットワーク。

alice-gw SPD

# to/from bob
spdadd 10.1.1.48/28[any] 10.1.1.64/28[any] any
-P out ipsec esp/tunnel/10.1.1.34-10.1.1.35/require ;
spdadd 10.1.1.64/28[any] 10.1.1.48/28[any] any
-P in ipsec esp/tunnel/10.1.1.35-10.1.1.34/require ;

bob-gw SPD

# to/from alice
# intentional misconfiguration for testing - no ESP to alice
spdadd 10.1.1.64/28[any] 10.1.1.48/28[any] any -P out none ;
#spdadd 10.1.1.64/28[any] 10.1.1.48/28[any] any
# -P out ipsec esp/tunnel/10.1.1.35-10.1.1.34/require ;
spdadd 10.1.1.48/28[any] 10.1.1.64/28[any] any -P in ipsec esp/
tunnel/10.1.1.34-10.1.1.35/require ;

不適切なコードの例
　2001年11月26日より netbsd-1-5 NetBSD を使用して alice-gw 側の黒いネットワークを試し、平文 SYN を調べる。平文 SYN の後にAlice からの応答による IKE を開始するalice-gw、再伝送されたSYN そしてESP のリセットと続く：

09:44:45.258912 bob.65514 > alice.8001: S 406012389:406012389(0) win 16384
09:44:45.260843 alice-gw.isakmp > bob-gw.isakmp: isakmp: phase 1 I
ident: (sa: doi=ipsec situation=identity (p: #1 protoid=isakmp
transform=1 (t: #1 id=ike (type=lifetype value=sec)(type=lifeduration value=0258)(type=enc value=3des)(type=auth value=rsa sig)(type=hash value=sha1)(type=group desc value=modp1024))))
09:44:45.262261 bob-gw.isakmp > alice-gw.isakmp: isakmp: phase 1 R
ident: (sa: doi=ipsec situation=identity (p: #1 protoid=isakmp
transform=1 (t: #1 id=ike (type=lifetype value=sec)(type=lifeduration value=0258)(type=enc value=3des)(type=auth value=rsa sig)(type=hash value=sha1)(type=group desc value=modp1024)))) (vid: len=16)
09:44:45.345226 alice-gw.isakmp > bob-gw.isakmp: isakmp: phase 1 I
ident: (ke: key len=128) (nonce: n len=16) (vid: len=16)
09:44:45.426774 bob-gw.isakmp > alice-gw.isakmp: isakmp: phase 1 R
ident: (ke: key len=128) (nonce: n len=16) (vid: len=16) (cr: len=1 type=x509sign)
09:44:45.545348 alice-gw.isakmp > bob-gw.isakmp: isakmp: phase 1 I
ident[E]: [|id]
09:44:45.576906 bob-gw.isakmp > alice-gw.isakmp: isakmp: phase 1 R
ident[E]: [|id]
09:44:45.577171 bob-gw.isakmp > alice-gw.isakmp: isakmp: phase 2/
others R inf[E]: [|hash]
09:44:45.582749 alice-gw.isakmp > bob-gw.isakmp: isakmp: phase 2/
others I inf[E]: [|hash]
09:44:46.588822 alice-gw.isakmp > bob-gw.isakmp: isakmp: phase 2/
others I oakley-quick[E]: [|hash]
09:44:46.590693 bob-gw.isakmp > alice-gw.isakmp: isakmp: phase 2/
others R oakley-quick[E]: [|hash]
09:44:46.591449 alice-gw.isakmp > bob-gw.isakmp: isakmp: phase 2/
others I oakley-quick[E]: [|hash]
09:44:51.217057 bob.65514 > alice.8001: S 406012389:406012389(0) win 16384
09:44:51.217686 alice-gw > bob-gw: ESP(spi=29712172,seq=0x1)

Alice の赤いネットワーク上で、我々は SYN とその応答（TCP リセット）を調べる：

09:44:45.258949 bob.65514 > alice.8001: S 406012389:406012389(0) win 16384
09:44:45.259415 alice.8001 > bob.65514: R 0:0(0) ack 406012390 win 009:44:51.217090 bob.65514 > alice.8001: S 406012389:406012389(0) win 16384
09:44:51.217540 alice.8001 > bob.65514: R 0:0(0) ack 1 win 0

変更コードの例
　ここでは、alice-gw 側で観察された黒いネットワークを調べる。一つの NTP 交換は、変更されずそのままだ。そうでなければ、赤の tcpdump は空になるだろう。（セキュリティ・ポリシーは、観察されたNTP トラフィックが ESP にあることを求めてない。）

09:58:25.886014 bob.65513 > alice.8001: S 2189637913:2189637913(0) win16384
09:58:31.664971 bob.65513 > alice.8001: S 2189637913:2189637913(0) win16384
09:58:43.664091 bob.65513 > alice.8001: S 2189637913:2189637913(0) win16384
10:00:06.991381 alice.ntp > tai.ntp: v4 client strat 3 poll 6 prec -17[tos 0x10]
10:00:06.991559 tai.ntp > alice.ntp: v4 server strat 3 poll 6 prec -18[tos 0x10]
09:59:07.662368 bob.65513 > alice.8001: S 2189637913:2189637913(0) win16384

ここで、我々は alice-gw 側で観察された赤いネットワークを調べる：
10:00:06.991356 alice.ntp > tai.ntp: v4 client strat 3 poll 6 prec -17[tos 0x10]
10:00:06.991579 tai.ntp > alice.ntp: v4 server strat 3 poll 6 prec -18[tos 0x10]

変更コードを使用して我々は、TCP SYN を送信した直前および直後に alice-gw 側の"netstat -p ipsec -s" の出力を検出した。

ipsec:
0 首尾よく処理されたインバウンド・パケット
0 プロセス・セキュリティ・ポリシーに反したインバウンド・パケット
0 利用可能なSA を持たないインバウンド・パケット
0 正当でないインバウンド・パケット
0 メモリー不足が原因で失敗したインバウンド・パケット
0 SPI の取得に失敗したインバウンド・パケット
0 AH 応答チェックに失敗したインバウンド・パケット
0 ESP の応答チェックに失敗したインバウンド・パケット
0 正当とみなされるインバウンド・パケット
0 認証に失敗したインバウンド・パケット
0 首尾よく処理されたアウトバウンド・パケット
0 プロセス・セキュリティ・ポリシーに反したアウトバウンド・パケット 0 利用可能なSA を持たないアウトバウンド・パケット
0 正当でないアウトバウンド・パケット
0 メモリー不足が原因で失敗したアウトバウンド・パケット
0 ルートを持たないアウトバウンド・パケット

ipsec:
0 首尾よく処理されたインバウンド・パケット
4 プロセス・セキュリティ・ポリシーに反したインバウンド・パケット
0 利用可能なSA を持たないインバウンド・パケット
0 正当でないインバウンド・パケット
0 メモリー不足が原因で失敗したインバウンド・パケット
0 SPI の取得に失敗したインバウンド・パケット
0 AH 応答チェックに失敗したインバウンド・パケット
0 ESP の応答チェックに失敗したインバウンド・パケット
0 正当とみなされるインバウンド・パケット
0 認証に失敗したインバウンド・パケット
0 首尾よく処理されたアウトバウンド・パケット
0 プロセス・セキュリティ・ポリシーに反したアウトバウンド・パケット 0 利用可能なSA を持たないアウトバウンド・パケット
0 正当でないアウトバウンド・パケット
0 メモリー不足が原因で失敗したアウトバウンド・パケット
0 ルートを持たないアウトバウンド・パケット

変更
NetBSD netbsd-1-5 用:
Index: src/sys/netinet/ip_input.c

RCS file: /NETBSD-CVS/netbsd/src/sys/netinet/ip_input.c,v
改訂版 1.1.1.1
diff -u -r1.1.1.1 ip_input.c
─ src/sys/netinet/ip_input.c 2001/07/05 14:42:54 1.1.1.1
+++ src/sys/netinet/ip_input.c 2002/02/25 01:07:02
@@ -611,6 +611,15 @@
ipstat.ips_cantforward++;
m_freem(m);
} else {
+#ifdef IPSEC
+ /*
+ * Enforce inbound IPsec SPD.
+ */
+ if (ipsec4_in_reject(m, NULL)) {
+ ipsecstat.in_polvio++;
+ goto bad;
+ }
+#endif
/*
* ip_dst が !IFF_UP インターフェース上の私のアドレスのいずれかに適合した場合、* ip_dst に適合するIFF_UP インターフェースはない、　
FreeBSD RELENG_4 用:
Index: src/sys/netinet/ip_input.c

RCS ファイル: /FREEBSD-CVS/src/sys/netinet/ip_input.c,v
改訂版 1.130.2.31
diff -u -r1.130.2.31 ip_input.c
─ src/sys/netinet/ip_input.c 2001/12/15 01:06:27 1.130.2.31
+++ src/sys/netinet/ip_input.c 2002/02/24 16:10:26
@@ -625,8 +625,18 @@
if (ipforwarding == 0) {
ipstat.ips_cantforward++;
m_freem(m);
- } else
+ } else {
+#ifdef IPSEC
+ /*
+ * Enforce inbound IPsec SPD.
+ */
+ if (ipsec4_in_reject(m, NULL)) {
+ ipsecstat.in_polvio++;
+ goto bad;
+ }
+#endif /* IPSEC */
ip_forward(m, 0);
+ }
#ifdef IPFIREWALL_FORWARD
ip_fw_fwd_addr = NULL;
#endif

ベンダーの対応：
　このアドバイザリは公表前に KAME、NetBSD、FreeBSD に提供した。我々が行った前述の変更もしくはそれに相当するするものは既に、KAME の CVS リポジトリ(NetBSD、1.37 そしてFreeBSD-4,1.33 用)、NetBSD - 現行バージョン(1.145) そして1.5 - 安定バージョン(1.114.4.8)、そして FreeBSD - 現行バージョン(1.192) そして - 安定バージョン(1.130.2.35) の sys/netinet/
ip_input.c に組み込まれている。

追加情報
Greg Troxel がこの情報を提供した。

［情報提供：SecuriTeam］
http://www.securiteam.com/

《ScanNetSecurity》