10月 052014
 

shellshock

ここのところ色々と話題になっている Shell Shock 問題、顧客からの問い合わせで色々大変な思いをしているケースもあると思う。 特に今回の Shell Shock は一度のパッチですべてを解決できなかったこともあり、相当大変だったと思う。JPCERT の脆弱性情報も対応するパッチ情報で「以下」と「未満」を間違えていたりと、どれが正しいのかよく分からない状況だった。

そんな場合に問題になるのが、サポート対象外となってもリプレイスできない、リプレイスするためのリソースを割り当てられない CentOS 4.x の対応。

Miracle Linux の SRPM を持ってきてコンパイルするという話もあるが、個人的に色々追ってパッチを適用していたりすると Miracle Linux よりも速かったので、個人的にパッチを追って RPM を作って対応していた。

Shell Shock 関連の CVE は

  • CVE-2014-6271
  • CVE-2014-6277
  • CVE-2014-6278
  • CVE-2014-7169
  • CVE-2014-7186
  • CVE-2014-7187

と 6 つある。CVE-2014-6271 は任意のコードの実行が可能なのに対し、CVE-2014-7169 は実害なし、CVE-2014-7186 と CVE-2014-7187 は DDoS、CVE-2014-6277, CVE-2014-6278 は segfault を引き起こすだけなのですべてのインパクトが等しく高いかというとそうでもない

ただ、B2B のビジネスをやっていると上記について等しい深刻度で突っ込まれがちなので、対応せざるを得ない状況というのがある。今抱えているプロダクトもそうなのだが、ことそのプロダクトが CentOS 4.x で動いていると、update が終了しているためにどう対応するかがそもそもの問題となる。そもそもの問題として、CentOS 4.x が残っているというのは CentOS 5.x 以降にアップグレードするリソースすら割り振れないわけで。

そんな状況なので、本家の ftp から持ってきたパッチをそのまま適用した rpm を作成してみた。

i386 向けまたは x86_64 向けを用意してあるので、アーキテクチャにあったものをダウンロードの上、rpm -Uvh でインストールすれば ok となる。

基本的に本家のパッチをそのまま当てているが、ベースとして使った bash-3.0-27.el4.src.rpm に含まれるオリジナルの bash.specbash30_16 のみコメントアウトされていたので、そこはそのままにしておいた。 なお、公式パッチよりもリビジョン番号が進んでいるのは、CVE-2014-7169 対応でメーリングリストに流れた修正コードを元に一度自前パッチを作っているためとなる。

なお、お約束として、この rpm はノークレームノーリターンノーサポートとなる。弊社本環境および一部受託環境で問題なく動作はしているが、あくまでも自己責任でお願いしたい。


Comments

comments

Powered by Facebook Comments