============================================================================= FreeBSD-SA-01:52 Security Advisory FreeBSD, Inc. トピック: フラグメント化された IPv4 packets を用いたサービス拒否攻撃 分類: kernel 告知日: 2001-08-06 クレジット: "James Thomas" via NetBSD 影響範囲: FreeBSD 3.x, 4.4 以前の 4.x 修正日以前の FreeBSD 4.3-STABLE 修正日: 2001-06-16 23:48:04 UTC (FreeBSD 4.3-STABLE) 2001-08-05 23:08:26 UTC (RELENG_4_3) 2001-08-06 09:20:57 UTC (FreeBSD 3.5.1-STABLE) FreeBSD 固有: NO I. 背景 - Background The IP protocol allows datagrams (``packets'') to be fragmented in transit to allow transportation by lower layers with a smaller frame size than the desired IP datagram size. The fragments are collected and reassembled on the destination system. IP プロトコルは、IP データグラムのサイズが求めるよりも小さな フレームサイズをもつ下位レイヤでの伝送を可能にするために、 伝送時にデータグラム（パケット）のフラグメント化を許可している。 フラグメント化されたパケットは、宛先のシステム上で収集・再構成される。 II. 問題の詳細 - Problem Description Remote users may be able to prevent a FreeBSD system from communicating with other systems on the network by transmitting large numbers of fragmented IPv4 datagrams. For the attack to be effective, the attacker must have a high-bandwidth connection to the target system (for example, connected via a local network or over a fast remote network connection). 大量のフラグメント化された IPv4 データグラムを送ることにより、 FreeBSD システムとネットワーク上の他のシステムとのコミュニケーションを リモートユーザが妨害できる。この攻撃が有効であるためには、攻撃者は 目標のシステムへの広帯域の接続を必要とする。（例えば、ローカル ネットワーク経由や高速なリモートネットワークによる接続） IP datagram fragments destined to the target system will be queued for 30 seconds, to allow fragmented datagrams to be reassembled. Until recently, there was no upper limit in the number of reassembly queues. Therefore, a malicious party may be able to transmit a lot of bogus fragmented datagrams (with different IPv4 identification field) and cause the target system to exhaust its mbuf pool, preventing further network traffic processing or generation while the starvation condition continues. 目標のシステム宛てのフラグメント化された IP データグラムは、再構築の ために３０秒間キューに溜められる。最近までは、再構築キューには 上限が設定されていなかった。しかし、悪意のある集団は、大量の偽造した フラグメント化されたデータグラム（異なった IPv4 ID フィールドを持つ） を送りつけることにより、目標のシステムの mbuf プールを使い果たさせ、 飢餓状態が続く間、それ以上のネットワークトラフィックの処理や生成を 妨害できる可能性がある。 To solve this problem an upper limit was placed on the number of fragment reassembly queues. This value is tunable at runtime using the net.inet.ip.maxfragpackets sysctl: the sysctl is set to a default value at system startup but may be tuned up or down depending on the role of the system (e.g. if the system is a busy server which typically receives a lot of fragmented datagrams, you may want to set the value higher). The old system behaviour of an unlimited number of reassembly queues can be obtained by setting this sysctl to a negative value. この問題を解決するためには、フラグメント再構築キュー数の上限を 設定すればよい。この値は、net.inet.ip.maxfragpackets の sysctl を 設定することで実行時に変更できる。（この値は起動時に自動的にデフォルト の値が設定されるが、システムの役割によってチューンナップしてもよい。 （例．もしシステムがいつも大量のフラグメント化されたデータグラムを 受け取るビジーなサーバであれば、この値を高く設定したいと考える人が いるかもしれない） 古いシステムでは、この sysctl を負の値に設定 すると再構築キュー数が無制限になる。 Note however that attackers are still able to prevent legitimate fragmented IPv4 traffic from being reassembled by flooding the system with bogus fragmented datagrams and keeping the reassembly queues full. Unfragmented IPv4 communications will be unaffected by such an attack when this variable is set. しかし、それでもまだこの攻撃者は、偽のフラグメント化されたデータグラムを 溢れさせ、再構築キューを一杯にし続けることで、合法的なフラグメント化され た IPv4 トラフィックを妨害できることに注意せよ。フラグメント化されて いない IPv4 通信は、この値を設定すればこのような攻撃による影響を受けない。 All versions of FreeBSD 3.x and 4.x prior to the correction date including 3.5.1-RELEASE and 4.3-RELEASE are vulnerable to this problem, although exploitation is mitigated by the need for high-bandwidth access to the target machine. 3.5.1-RELEASE と 4.3-RELEASE を含む FreeBSD 3.x と 修正日以前の 4.x には、この問題による脆弱性が存在する。しかし、目標のマシンへの 広帯域なアクセスが必要なため、この脆弱性を利用した攻撃の脅威は 和らげられる。 III. 影響範囲 - Impact IPv4-connected systems can be put into a resource-starved state from which they are unable to send or receive network traffic by the constant bombardment of the system by fragmented datagrams. IPv4 によって接続されたシステムは、フラグメント化されたデータグラム による継続的な攻撃により、ネットワークトラフィックの送受信が行えない リソースの飢餓状態に陥らせることができる。 IV. 回避方法 - Workaround A possible workaround for systems which are under active attack is to increase the value of the NMBCLUSTERS kernel option on attacked machines and rebuild the kernel as described in the following URL: 攻撃を受けているシステムの可能な代替手段は、以下の URL で記述されて いるように、攻撃を受けているマシンのカーネルオプション NMBCLUSTERS の値を増やし、カーネルを再構築することである。 http://www.freebsd.org/handbook/kernelconfig.html This may provide a temporary solution until the patch can be applied: normally, it is the cluster mbufs which are exhausted by this attack. By setting NMBCLUSTERS to a higher value, you may be able to prevent the mbuf memory pool from being starved. これは、パッチが適用されるまでの一時的な解決になるかもしれない。 （通常、この攻撃によって mbuf のクラスタは使い果たされる。NBMCLUSTERS をより高い値に設定することで、mbuf のメモリプールの飢餓状態を防ぐこと ができるかもしれない。） VI. 回避方法 - Solution One of the following: 以下のいずれかを実行する: 1) Upgrade your vulnerable FreeBSD system to 4.3-STABLE or the RELENG_4_3 security-fix branch dated after the correction date. 1) 脆弱性のある FreeBSD システムを修正日以降の 4.3-STABLE や RELENG_4_3 security-fix ブランチにアップグレードする。 2) To patch your present system: download the relevant patch from the below location, and execute the following commands as root: 2) 現在のシステムにパッチを適用する。以下の場所から、関連したパッチを ダウンロードし、root で以下のコマンドを実行する。 [FreeBSD 4.x] This patch has been verified to apply to FreeBSD 4.2-RELEASE and 4.3-RELEASE systems. It may or may not apply to older, unsupported releases. 以下のパッチは FreeBSD 4.2-RELEASE と FreeBSD 4.3-RELEASE で適用を 確認している。これより古いサポートされていないバージョンへの 適用は不明である。 # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:52/frag-4.x.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:52/frag-4.x.patch.asc [FreeBSD 3.x] This patch has been verified to apply to FreeBSD 3.5.1-RELEASE systems. It may or may not apply to older, unsupported releases. このパッチは、FreeBSD 3.5.1-RELEASE システムへの適用を確認している。 それより古いサポート外のリリースへの適用は不明である。 # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:52/frag-3.x.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:52/frag-3.x.patch.asc Verify the detached PGP signature using your PGP utility. PGP ユーティリティを使用して PGP シグネチャを確認する。 # cd /usr/src/ # patch -p < /path/to/patch Rebuild the kernel as described in the following URL: 以下の URL の説明に従ってカーネルを再構築する。 http://www.freebsd.org/handbook/kernelconfig.html 3) FreeBSD 4.3-RELEASE systems: An experimental upgrade package is available for users who wish to provide testing and feedback on the binary upgrade process. This package may be installed on FreeBSD 4.3-RELEASE systems only, and is intended for use on systems for which source patching is not practical or convenient. バイナリアップグレードの処理のテストとフィードバックをしてくれる ユーザのため、実験的なアップグレードパッケージが利用可能である。この パッケージは、FreeBSD 4.3-RELEASE システムのみにインストールでき、 ソースへのパッチ当てが現実的ではなかったり、都合が悪かったりする システムで利用することを意図している。 If you use the upgrade package, feedback (positive or negative) to security-officer@FreeBSD.org is requested so we can improve the process for future advisories. もしアップグレードパッケージを利用するなら、将来の勧告の処理を改良 できるように、security-officer@FreeBSD.org にフィードバック （肯定・否定問わず）してください。 Since this vulnerability involves the FreeBSD kernel which is often locally customized on installed systems, a universal binary upgrade package is not feasible. This package includes a patched version of the GENERIC kernel which should be suitable for use on many systems. Systems requiring a customized kernel must use an alternative solution. この脆弱性は、インストールされたシステム向けにカスタマイズされている ことが多い FreeBSD のカーネルに含まれているため、一般的なバイナリ アップグレードパッケージは作成できない。このパッケージは、パッチが 当てられたバージョンの GENERIC カーネル（様々なシステムでの利用に適し ている）含んでいる。カーネルのカスタマイズが必要な場合は、他の解決法 を利用しなければならない。 During the installation procedure, backup copies are made of the files which are replaced by the package. These backup copies will be reinstalled if the package is removed, reverting the system to a pre-patched state. インストール中に、パッケージによって置き換えられるファイルの バックアップコピーが作成される。これらのバックアップコピーは、 システムをパッチを当てる前の状態に戻すとき、パッケージを削除した あとに再インストールできる。 # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/packages/SA-01:52/security-patch-fragment-01.52.tgz # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/packages/SA-01:52/security-patch-fragment-01.52.tgz.asc Verify the detached PGP signature using your PGP utility. PGP ユーティリティを仕様して PGP シグネチャを確認する。 # pkg_add security-patch-fragment-01.52.tgz The new kernel is named /kernel.GENERIC to avoid conflict with the default kernel name (``/kernel''). To cause the system to boot automatically with the new kernel, add the following line to /boot/loader.conf: 新しいカーネルは、デフォルトのカーネル名(``/kernl'')との衝突を避ける ため、/kernel.GENERIC と呼ばれている。システムが自動起動できるように、 以下の行を /boot/loader.conf に追加する。 kernel="/kernel.GENERIC" and reboot the system to load the new kernel. The old kernel is still available and can be manually loaded in the boot loader in case of problems. そして、新しいカーネルをロードするためにシステムを再起動する。 古いカーネルはまだ利用可能なので、問題があった場合にはブートローダ から手動でロードすることができる。 VII. クレジット/参考文献 - Credits/References NetBSD wrote the original advisory from which large portions of this advisory was taken. NetBSD は、この勧告が大部分を引用した勧告の原文を書いている。