さくらのVPS(CentOS6.5)でglibcの脆弱性(CVE-2015-7547)に対処した方法まとめ

さくらのVPS

※当ブログではアフィリエイト広告を利用しています。

2/16にLinuxのアプリケーションで広く使われているライブラリ「glibc」の脆弱性が公開されました。緊急性の高い脆弱性のようで各種メディアでも注意喚起されています。

当サイトはさくらVPSのCentOS6.5で稼働しており、脆弱性の影響を受ける可能性があるため対策を行いました。その手順をメモします。

CVE-2015-7547について

glibcにバッファオーバーフローの脆弱性が存在し、遠隔の攻撃者により意図しないコードが実行される可能性があるとのことです。本エントリ公開時点ではIPAのサイトには情報が見当たりませんでしたが、脆弱性対策情報ポータルサイト「JVN」とJPCERTには情報が出ていました。

以下は本脆弱性についての詳細をJVNのサイトから引用したものです。

詳細情報
glibc には、send_dg() および send_vc() の処理に起因するスタックベースのバッファオーバーフローの脆弱性が存在します。

想定される攻撃
遠隔の攻撃者によって、任意のコードを実行されたり、サービス運用妨害 (DoS) 攻撃を受けたりする可能性があります。

対策方法
アップデートする
各開発者が提供する情報をもとに、アップデートを適用してください。

CentOS 6.5での対策済みglibcのバージョンは2.12-1.166.el6_7.7です。

関連リンク:glibc ライブラリの脆弱性 (CVE-2015-7547) に関する注意喚起

以下のように一時的に凌ぐ方法もあるようですが、根本的な対策方法としてはglibcをアップデートし、glibcを使用しているプロセスを再起動またはOSごと再起動するのが最も良いようです。

関連リンク:glibcの脆弱性対策(取り急ぎiptables/firewalldで叩き落とす!)for CVE-2015-7547 – Qiita

さくらのVPS(CentOS6.5)でglibcの脆弱性(CVE-2015-7547)に対処した方法

当サイトで使用しているさくらのVPSはCentOS6.5を使用しているため、脆弱性の影響を受ける可能性があります。下記のQiitaで公開されている方法で実際に対応してみたのでその方法をメモします。

関連リンク:CVE-2015-7547のRedHat/CentOS系 – Qiita

現在のglibcバージョンの確認

以下のコマンドでバージョンを確認しました。当然ながら対策されていないバージョンです。

$ yum -q list installed glibc
Installed Packages
glibc.x86_64          2.12-1.132.el6_5.3          @updates

glibcのアップデート

yumリポジトリをきれいにしてからアップデートをかけます。

# yum clean all
Loaded plugins: downloadonly, fastestmirror, priorities, security
Cleaning repos: base epel extras nginx rpmforge updates
Cleaning up Everything
Cleaning up list of fastest mirrors
# yum update glibc
Loaded plugins: downloadonly, fastestmirror, priorities, security
Determining fastest mirrors

・・・中略・・・

Dependency Updated:
  glibc-common.x86_64 0:2.12-1.166.el6_7.7          glibc-devel.x86_64 0:2.12-1.166.el6_7.7          glibc-headers.x86_64 0:2.12-1.166.el6_7.7

Complete!

glibcのバージョンが上がっていることの確認

再度以下のコマンドでバージョンを確認します。対策済みバージョンとなっているためアップデート自体は完了です。

# yum -q list installed glibc
Installed Packages
glibc.x86_64          2.12-1.166.el6_7.7          @updates

反映のためにサーバ再起動

ちょっと乱暴ですがglibcを使用しているプロセスが多く(nginxやmysqldにはじまり約30個)、一つ一つ再起動するのが面倒なのでサーバ再起動しました。業務影響など一切関係ない個人サイトなのでできる技ですが・・・。

# reboot

サーバ再起動は5分もかからないうちに完了し、元通りサイトが閲覧可能な状態となりました。

おわりに

VPSは自由度が高い代わりに今回のような緊急度が高い脆弱性が発見された場合にヒヤヒヤします。しかしセキュリティに関する知識や対策方法を学ぶチャンスと考えることもできます。

仕事だけに限らずセキュリティに対するアンテナは日頃から高く張っていたいと思う出来事でした。