glibc パッケージには、システム上の複数のプログラムによって使用される標準のライブラリーが含まれています。ディスクの容量とメモリーを節約し、アップグレードを容易にするため、共通のシステムコードは 1 つの場所に格納され、プログラムの間で共有されます。このパッケージには標準の C ライブラリーが含まれ、すべての GNU/Linux プログラムがリンクされています。glibc に同梱される libresolv ライブラリーは、ホスト名と IP アドレス間の変換を行う機能を提供します。nss_dns は、libresolv を使用して DNS ルックアップを行う Name Service Switch (NSS) サービスモジュールを提供する glibc コンポーネントです。

背景

libresolv のデュアル A/AAAA DNS クエリーを実行するコードに、スタックベースのバッファーオーバーフローが見つかりました。遠隔の攻撃者は、libresolv をクラッシュしたり、ライブラリーを実行しているユーザーのパーミッションを使用してコードを実行可能な特殊な DNS 応答を作成できる可能性があります。バッファーオーバーフローは、libresolv の関数 send_dg (UDP クエリーの場合) および send_vc (TCP クエリーの場合) で発生します。この問題は、libresolv が nss_dns NSS サービスモジュールから呼び出された場合のみ公開されます。この問題は CVE-2015-7547 に登録されました。

AF_UNSPEC アドレスファミリーを使用して getaddrinfo を呼び出すアプリケーションが影響を受けますが、Red Hat Enterprise Linux 6.4 では AF_INET6 アドレスファミリーを使用するアプリケーションも影響を受けます。以前の gethostbyname 関数や、res_search などの libresolv 関数 (getaddrinfo ではない) は影響を受けません。

この問題は、Red Hat Enterprise Linux 5 以前に同梱されたバージョンの glibc には影響しません。この問題は、Red Hat Enterprise Linux 6 および 7 に同梱されたバージョンの glibc に影響します。

影響

この問題は Red Hat Product Security チームによって 重大な影響 と評価されました。

軽減策

デフォルトの libresolv 設定では、信頼されるネットワークで信頼されるプロトコル対応の DNS リゾルバーを使用すると UDP ベースのベクトルを軽減できます。デフォルトでは glibc レゾルバーは EDNS0 を有効化せず、大型の応答を要求しないため、プロトコル対応のリゾルバーはこの脆弱性を悪用するために必要なサイズの大きな応答を作成しません。

TCP ベースのベクトルは、各 DNS 応答のサイズを 1023 バイト以下に制限する信頼されるネットワークの信頼される再帰的リゾルバーによって軽減できる可能性があります。しかし、このような機能は DNS プロトコルに違反するため、DNS 実装では一般的ではありません (ほとんどリゾルバーによって提供されるバッファーサイズ設定オプションは UDP のみに適用され、TCP には適用されません)。A 応答のサイズを制限せずに AAAA 応答を拒否しても、脆弱性は軽減されません。

デュアル A/AAAA ルックアップは IPv6 のサポートがなくても実行されるため、影響を受けるシステムの IPv6 サポートを無効にしても脆弱性は軽減されません。

影響を受ける製品と解決策

Red Hat Enterprise Linux 6 および 7 に含まれるすべてのバージョンの glibc パッケージがこの問題の影響を受けます。この問題の修正に関するセキュリティーアドバイザリーのリンクについては、以下の表をご覧ください。

解決策

アップデートの適用後、システムまたは影響を受けたサービスすべてを再起動する必要があります。

この脆弱性はシステム上の多くのアプリケーションに影響するため、システムを再起動して、すべてのアプリケーションが更新された glibc パッケージを確実に使用するようにすることが最も安全であり、推奨されます。

アップデートの適用後にシステム全体を再起動できない場合は、以下のコマンドを実行し、更新前の [インメモリー] バージョンの glibc をシステムで使用している稼働中のプロセスをすべて一覧表示します。

lsof +c0 -d DEL | awk 'NR==1 || /libc-/ {print $2,$1,$4,$NF}' | column -t

この一覧よりパブリック向けサービスを識別し、再起動します。これは、一時的な回避策として機能しますが、Red Hat ではサポートされません。問題が発生した場合には、トラブルシューティングを行う前にシステムの再起動が要求されます。

よくある質問とその答え (FAQ)

1. このセキュリティー問題は SELinux によってブロックされますか?
適切な SELinux ポリシーには攻撃者による被害の一部が含まれる可能性があり、システムへのアクセスを制約できる可能性がありますが、DNS は多くのアプリケーションやシステムコンポーネントによって使用されるため、SELinux ポリシーによるこの問題の抑制は限定的です。

2. 信頼される DNS 再帰的リゾルバーを使用すると、この問題を防ぐことはできますか?
構文が巧妙に形成された DNS 応答が悪用される可能性があるため、デフォルトのプロトコル対応設定の信頼される再帰的リゾルバーはこの問題を軽減できません。再帰的リゾルバーと glibc の影響を受けるバージョンを使用するクライアント間のネットワークが信頼される場合は、応答サイズを 1023 バイト以下に制限することによって問題を軽減でき、再帰的リゾルバーのソースアドレスの攻撃者によるなりすましを防止できます。パケットサイズの制限は、インターネットから受信される応答ではなく、再帰的リゾルバーが生成する応答に適用される必要があります。このようなパケットサイズの制限は、DNSSEC を含む一部の DNS 関連のサービスを中断させる可能性があります。サイズを制限する以外に、DNS recursor で攻撃トラフィックを検出し、これをブロックする方法はありません。

3. インターネットに接続する DNS サーバーと再帰的リゾルバーをアップグレードするだけで十分ですか?
いいえ。すべてのホスト (サーバーとクライアントの両方) の glibc パッケージをアップデートする必要があります。

4. TCP モードは /etc/resolv.conf で有効にされていませんが、システムは依然としてこの不具合の影響を受けるでしょうか?
スタブリゾルバーは、応答サイズが UDP バッファーサイズ (デフォルトで 512 バイト) を超えると自動的に TCP に切り替えます。そのため、TCP が明示的に有効にされていなくても、システムは TCP ベースのベクトルにさらされます。

5. デュアル A/AAAA DNS ルックアップを回避することは可能ですか?
アプリケーションによっては、デュアルルックアップ (AF_UNSPEC) から IPv4 (AF_INET、A レコード) または IPv6 (AF_INET6、AAAA レコード) ルックアップのみに切り換えるオプションがあります。通常、コマンドラインのオプションは -4 および -6 になります。この軽減方法はアプリケーションごとに適用する必要があります。現時点で、AF_UNSPEC ルックアップを A レコードまたは AAAA レコードのルックアップに切り換えるグローバルスイッチはありません。single-request および single-request-reopen オプションを使用しても保護策とはなりません。

6. この攻撃を /etc/nsswitch.conf で軽減することはできますか?
dns サービスモジュールが /etc/nsswitch.conf に一覧表示されていない場合、システムがこの問題の危険にさらされることはありません。ただし、標準的な glibc 名前解決機能を使って DNS ルックアップを実行することはできなくなるため、この軽減方法が有効になることはほとんどありません。

7. システムを信頼される DNS サーバーのみに接続させることによってこの脆弱性を軽減することはできますか?
理論上は可能ですが、システムがインターネットに接続されると、システムが予期しない名前を使用して予期しない DNS クエリーを行う可能性があります。これにより、(設定される再帰的リゾルバーから) 信頼されない DNS サーバーのデータが取得される可能性があります。

8. 静的にリンクされたバイナリーはこの不具合の影響を受けますか?
Red Hat は glibc の静的リンクはサポートしていません。しかし、glibc-static パッケージを使用して静的にリンクされたアプリケーションを構築した場合、これらのアプリケーションは nss_dns および libresolv のシステムコピーを使用するため、更新された glibc パッケージをインストールすることで脆弱性が修正されます。

謝辞

この脆弱性は Google セキュリティーチームおよび Red Hat によって発見されました。