glibcのgetaddrinfo()問題 – CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow

(更新日: 2016/02/22)

CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow として2/16に公開されたセキュリティ問題に対するアクセスが多いようですが、古いglibcのページがヒットするようなので簡単にまとめておきます。コードレベルで詳しくは見ていません。詳しい事は他の方がまとめてくれると思います。この検索してこのブログに来てしまった方向けに簡単に紹介します。

GHOSTとは別の問題

RHEL6のglibcのパッチを見るとGHOSTとして知られるgethostbyaddr()の問題とは別の問題です。”参考”に記載したsourcewareのバグレポートからも別の問題だと分かります。

攻撃の方法

攻撃用のDNSサーバーを作ってgetaddrinfo()が脆弱なサーバーのプログラムにこの関数を呼び出させます。この関数はネットワーク関連のプログラムで呼び出されることが多く、ネットワークを扱うプログラムの大半で利用されていると思われます。

“CVE-2015-7547 仕組み”をキーワードとした検索も多いようなので追記します。脆弱性の仕組みは

の”High-level Analysis”と”Detailed Analysis”を参照してください。

攻撃が成功した場合の影響

2.9以降(2008年5月)のglibcに影響し、攻撃に成功すると攻撃対象のプログラムから任意コードが実行されます。

攻撃が失敗した場合の痕跡

攻撃されたプログラムがクラッシュします。不信なクラッシュを検出すれば攻撃されていることが分かります。DNSパケットを監視することでも攻撃は検出/防止できます。

この攻撃は”スタックオーバーフロー”としてGoogleのブログでは紹介されています。最終的には2KBのスタック変数のスタックオーバーフローで62KB程度のメモリが攻撃に利用できるようです。最近のプログラムはスタックオーバーフロー対策付きでコンパイルされているので、単純にオーバーフロー=攻撃成功とはなりません。また、スタック領域にコピーされるメモリ領域はヒープ領域なので攻撃に失敗した場合はASLRで保護されます。(ASLRによる保護は完全ではありません。Googleのブログでは書かれていないですがカナリア値によるスタックオーバーフロー保護も多くの環境で働くはずです)

緩和策/防御策

残念ながらgetaddrinfo()を利用するプログラム側での緩和策は仕組み的に無理だと思われ、利用するプログラムも多く現実的ではありません。防御策は以下の通りです。

  • glibcをアップデート(最良)
  • DNSで対応(ほぼOK。ただし単純に2KBを超えるDNSレスポンスを拒否すると問題となる可能性があるので、採用する場合は注意が必要)
  • SystemTapを使って防御(バグレポートで紹介されていますが、効果/副作用などは判りません)

AmazonのAWSで利用するデフォルトのDNSは対応済みらしく、設定を変えていないユーザーは大丈夫とAmazonがアナウンスしています。

メジャーなディストリビューションは修正版glibcを公開しています。rpm系なら

yum update glibc または dnf update glibc

で更新できるはずです。

 

対策にならない対策

以下のDNSサーバー設定、システム設定では対策になりません。

  • options single-requestを設定する
  • options single-request-reopenを設定する
  • IPv6を無効にする

 

まとめ

攻撃できないPoC、とはいえPoCが公開されており、バグの内容もかなり詳細に解説されており、パッチも当然公開されています。リスクは高いと思われます。早急に対策する必要があると思います。

 

参考

これを見るとごく単純なスタックオーバーフローではなく、メモリ割り当ての問題などで最終的にスタックオーバーフローになることが解ります。

  • CentOS 6のglibcのパッチ

 

 

Comments

comments

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です