はじめに
世間を騒がせている bashの脆弱性(愛称ShellShock) ですが、
大抵の場合は yum update bash で済むようですが、
おそらく古いEC2 Instanceの場合、一緒にglibcなどが更新されて思わぬ影響が出ることがあります。
※もちろん、AWSに限った話ではないです。
起こりえる事象として、今把握しているものは
- crond が機能しなくなる
- Apache+PHP の動作(host名解決など)が怪しくなる
などがあります。
検証
bash更新作業
2013.03 の AmazonLinux で
% cat /etc/issue
Amazon Linux AMI release 2013.03
Kernel \r on an \m
yum info bashしてみると以下の状態でした。
Loaded plugins: priorities, security, update-motd, upgrade-helper
Installed Packages
Name : bash
Arch : x86_64
Version : 4.1.2
Release : 14.16.amzn1
Size : 3.0 M
Repo : installed
From repo : amzn-main
Summary : The GNU Bourne Again shell
URL : http://www.gnu.org/software/bash
License : GPLv3+
Description : The GNU Bourne Again shell (Bash) is a shell or command language
: interpreter that is compatible with the Bourne shell (sh). Bash
: incorporates useful features from the Korn shell (ksh) and the C shell
: (csh). Most sh scripts can be run by bash without modification.
Available Packages
Name : bash
Arch : x86_64
Version : 4.1.2
Release : 15.19.amzn1
Size : 1.3 M
Repo : amzn-updates
Summary : The GNU Bourne Again shell
URL : http://www.gnu.org/software/bash
License : GPLv3+
Description : The GNU Bourne Again shell (Bash) is a shell or command language
: interpreter that is compatible with the Bourne shell (sh). Bash
: incorporates useful features from the Korn shell (ksh) and the C shell
: (csh). Most sh scripts can be run by bash without modification.
ここで bash を update しようとすると bash以外にも以下のものが更新されます。
% sudo yum update bash
===========================================================================================================
Package Arch Version Repository Size
===========================================================================================================
Updating:
audit x86_64 2.3.3-4.21.amzn1 amzn-main 261 k
bash x86_64 4.1.2-15.19.amzn1 amzn-updates 1.3 M
Updating for dependencies:
audit-libs i686 2.3.3-4.21.amzn1 amzn-main 85 k
audit-libs x86_64 2.3.3-4.21.amzn1 amzn-main 87 k
glibc i686 2.17-55.87.amzn1 amzn-main 6.0 M
glibc x86_64 2.17-55.87.amzn1 amzn-main 5.6 M
glibc-common x86_64 2.17-55.87.amzn1 amzn-main 28 M
glibc-devel x86_64 2.17-55.87.amzn1 amzn-main 1.1 M
glibc-headers x86_64 2.17-55.87.amzn1 amzn-main 721 k
nss-softokn-freebl i686 3.16.0-1.19.amzn1 amzn-main 187 k
nss-softokn-freebl x86_64 3.16.0-1.19.amzn1 amzn-main 219 k
Transaction Summary
===========================================================================================================
Upgrade 11 Package(s)
Total download size: 43 M
念のため
% sudo ldconfig
もしておきます。
crondが動かなくなる現象
１分に１回 echo OK するだけのcronをセットしておきます。
Sep 26 02:25:01 ip-xx-x-x-xxx CROND[30455]: (root) CMD (echo OK)
Sep 26 02:26:02 ip-xx-x-x-xxx crond[30562]: (root) FAILED to authorize user with PAM (Module is unknown)
Sep 26 02:27:01 ip-xx-x-x-xxx crond[30574]: (root) FAILED to authorize user with PAM (Module is unknown)
すると、更新直後(02:26)から CRONが実行されなくなりました。
この場合は crond を再起動すると直ります。
sudo service crond restart
Sep 26 02:29:39 ip-xx-x-x-xxx crond[30657]: (CRON) STARTUP (1.4.4)
Sep 26 02:29:39 ip-xx-x-x-xxx crond[30657]: (CRON) INFO (running with inotify support)
Sep 26 02:29:39 ip-xx-x-x-xxx crond[30657]: (CRON) INFO (@reboot jobs will be run at computer's startup.)
Sep 26 02:30:02 ip-xx-x-x-xxx CROND[30675]: (root) CMD (echo OK)
02:30でCronの実行が復活しているのがわかります。
その他
Apache+PHPの動作がおかしい場合
Apache+PHPの動作が怪しくなる場合もあるようです。
私が知っているケースではApache再起動でなおりました。
yum で update したんだけど、bash以外にも更新されているか覚えてない
大抵は /var/log/messages を見ると記録が残っていると思います。
AmazonLinux 2013.09の場合
ある AmazonLinux 2013.09 だと、bashのみの更新になってました。
全てそうなのかとかはよくわかりませんが、参考まで。
おわりに
可能ならサーバ再起動するのがやっぱり楽ですね。
それができないケースは、しばらく要監視、が必要になりそうです。
あと、最初のリンク先の記事にもありますように、
今(2014/09/26 12:00 JST)の段階で提供されているbashでは完全な対策ではないという話なので、
急いで対応する必要がないサーバでは、パッチがでるまでしばらく様子見、しても良いのではないかと思います。
※追記: 2014/09/30
もうご存知でしょうが、既に完全なPatchが提供されているようなので、速やかに適用するのが良いと思います。