Ubuntu Weekly Topics

2014年9月26日号 14.10の開発・“shellshock”とその対応・UWN#384

この記事を読むのに必要な時間:およそ 6.5 分

14.10のFinal Betaとそれに伴うテスト

14.10の開発は無事にFinal Betaに達し注1),恒例のテスト要請が行われています。14.10のリリースイメージに何らかのバグがあっては困る場合はテストを,あるいはすでにバグを見つけている場合は速やかな報告が必要なフェーズです。近年はこの時期のリリースであっても一部の例外を除いて比較的安定しているため注2),「次リリースを体験してみる」意味でも良いタイミングです。

ただし,あくまで開発版であり,リリース版に比べると実施されたQAの分量は少ないため,バックアップや予備機の準備は必須です。

なお,多言語入力回りについてはFcitxのMIRが現状でまだ完了しておらず,Unityへの組み込みが現在もまだ残務あり,という状態にあるため,まだどちらへ転ぶのかは未知数です。一度インストールしてしまえばIBus環境がセットアップされ,Fcitxが昇格してもその環境が壊れる可能性はあまりありませんが,なんらかの問題で日本語入力が期待通りに行えなくなる可能性はゼロではありません。テストを行う場合,他の常用環境を準備する,壊れても自力で直す覚悟をする,連絡を取る可能性のある相手に「英語の勉強のために,とつぜん英語だけでメールを書いたりするかもしれない」とあらかじめ伝えておく,といった対処をしておくと良いでしょう。

注1
基本的に(狭義の,つまりUbuntu Desktop/Serverを示す意味での)UbuntuはFinal Betaフェーズであってもベータリリース的なものは行わないので,無事に終わらない可能性はほとんどなく,無事に終わらない可能性はほぼ無視できるのですが,まれにCanonical製の新機能が投入されてしまい「なにをどうやっても無事とはいいがたい」状態に陥ることがあります。
注2
具体例は注1の後半部分です。

“shellshock”

9月24日深夜に,bashの「shellshock」と呼ばれる脆弱性CVE-2014-6271が公表されました。環境変数に悪意ある細工が施された文字列が含まれた状態でbashが実行されると,攻撃者が与えた任意のコマンドが実行できてしまう,というものです。

この問題への一般的な対策は次の通りです。

  • 1. サポート対象バージョンへの更新:現在もサポートが継続されているバージョンにアップグレードする。
  • 2. CVE-2014-6271への対応:対応パッケージにアップグレードする。
  • 3. CVE-2014-7169への対応:対応パッケージのリリースを待ち,アップグレードする。

9月25日深夜の段階では,3の段階の対応が進められており,「パッチとして提案されたものは存在するが,レビュー中」という段階です。コードレビューやQAにまだいくらかの時間が必要になる見込みです。一般的なユーザーであれば「3のリリースを待って確実にアップデートする」対応を行うことで問題を解決できます。

なんらかのサービスを提供中でこのリリースが待てない場合,以下のパッケージ更新以外の対応を行ってください。

  • 3':影響範囲をレビューする。また,もしも/bin/shがbashのsymlinkによって提供されている場合は,それを異なるプログラムによって代替することを検討する。
  • 3a:サービスを停止する。
  • 3b:暫定版パッチを適用したbashに置き換える。
  • 3c:なんらかのmitigationプログラムを利用する。

これらについて,Ubuntuでの対策は具体的には次の通りです。

2014年9月26日14:50 追記

その後状況が進展し,Ubuntuでは3.で利用するアップデートパッケージの提供が開始されました。アップデートマネージャーやapt-get update; apt-get upgrade bashを実行することで入手できます。アップデータを適用してください。

それぞれ,以下のバージョンであれば問題ありません。

  • 10.04 LTS: 4.1-2ubuntu3.2
  • 12.04 LTS: 4.2-2ubuntu2.3
  • 14.04 LTS: 4.3-7ubuntu1.3

注意すべき点として,14.04 LTS用のアップデートパッケージはusn-2363-1のリリース時点ではビルドに失敗しており,対応版とされる「4.3-7ubuntu1.2」(末尾が2)は未対応なままであったことです。usn-2363-2でリリースされた「4.3-7ubuntu1.3」(末尾が3)を利用してください。

この問題への対応において,追加の脆弱性(メモリ破壊バグ)をRed Hatが発見しており,CVE-2014-7186とCVE-2014-7187としてハンドリングされています。この2つの問題についてはUbuntuはまだ未対応で,近いうちにさらに更新が行われる予定です。ただし,shellshockの抑制という意味では上記のパッケージに更新されていれば問題はないため,これらへの対応を待つのではなく,現状でリリースされているパッケージへの更新を行なってください。

2014年9月29日13:50 追記

さらに別のパーサーの問題が存在することが公表されました。問題の追跡にはCVE-2014-6277を利用してください。

幸いなことに,この問題はUbuntu環境では大きな影響を及ぼすものではありません。根本的な対策ではないものの,usn-2364-1で取り込まれた関数インポート機能を特定のプリフィクスをもつ環境変数名に制約するパッチによって悪用を阻害できるためです。このパッチが含まれている以下のバージョンに更新されていることを確認してください。

usn-2364-1
  • 10.04 LTS: 4.1-2ubuntu3.4
  • 12.04 LTS: 4.2-2ubuntu2.5
  • 14.04 LTS: 4.3-7ubuntu1.4

この更新は「何があろうと今すぐ」対応しなければいけないCVE-2014-6271CVE-2014-7169への対応と異なり,「できるタイミングで更新すればよい」というレベルです。CVE-2014-6277を悪用する攻撃は“shellshock”本体とは違ってメモリ破壊を応用した攻撃のため,ASLRによって攻撃成功の可能性を著しく引き下げ,任意のコード実行ではなくクラッシュで済ませることができます。これよりも一つ古いusn-2363-2までの対応が行われていれば問題を回避できます(そして,ほとんどの環境では条件を満たしているはずです)。

ASLRによる保護を前提にした場合,更新されているべきバージョンは次の通りです。

usn-2363-1usn-2363-2
  • 10.04 LTS: 4.1-2ubuntu3.2
  • 12.04 LTS: 4.2-2ubuntu2.3
  • 14.04 LTS: 4.3-7ubuntu1.3

ただし,このバージョンの場合は外部からおかしな入力を行うことでbashをクラッシュさせることができるため,可能であればusn-2364-1レベルへの更新を推奨します。

Ubuntuでの「パッケージ更新以外の対応」は次の通りです。

  • 3':影響範囲のレビュー(1):「readlink /bin/sh」の結果がbashでないことを確認します。後述の情報も参照してください。
  • 3':影響範囲のレビュー(2):readlinkの結果に問題が無ければ,「bashを直接利用して提供している外部サービス」の有無を調査します。bashベースのCGIがなければたいていの環境では問題ないと判断できますが,外部サービスを提供している環境であれば,ロード中のプロセスすべてについて,「bash」の文字列が含まれていないことを確認するとある程度の安全が担保できます。「sudo strings /proc/*/exe | grep bash」の結果をレビューしてください。
  • 3':影響範囲のレビュー(3):より確実な判断が必要な場合は,/proc/*/mapsの第6フィールドに列挙された共有ライブラリすべてについてstringsを実行し,出力にbashが含まれていないことを確認します(ただし,この確認は簡易的なものなので,bashを別名で呼び出しているケースは漏れます)。

このレビュー結果を踏まえて,以下のいずれかの対応を行います。たいていのケースでは3bの暫定パッケージの導入が有効と考えられますが,該当のパッチは十分なレビューが行われていないため,未知の障害や非互換を引き起こす可能性があることに注意してください。

  • 3a:サービスの停止:HTTPdを始めとした,「bashを叩く可能性のあるサービス」を停止してください。たとえば,gitやsvn等のVCSのために利用コマンドを制約したSSHを提供している場合が該当します。
  • 3b:暫定版パッチを適用したbashへの置き換え:暫定パッチを適用したパッケージ(レビュー中のもの)が,Ubuntu Security Teamのテスト用PPAから入手可能です。PPAのリポジトリを有効にする方法ではなく,直接パッケージをダウンロードして導入してください。
  • 3c:なんらかのmitigationプログラム:今回の問題について,Ubuntu特有のmitigationは提供されていません。Red Hatの提供するmitigationプログラムを流用するか,UFWを用いてアクセス可能なネットワークを制約してください。通常の攻撃手法であればUFWのlimit機能によるアクセス回数の制限が有効ですが,本件では初回アクセスで攻撃として成立するアクセスが可能なため,limitによる防御はほぼ機能しません。

このレビューにおいて,「readlink /bin/shの結果がbashでないことを確認する」のくだりを理解するには,いくつかの前提知識が必要になります。

まず,Red Hat系ディストリビューションを利用している場合,/bin/shがbashのsymlinkになっているため,各種言語のシステムコマンド呼び出しが/bin/sh経由で行われる→実体はbash→ここに環境変数が渡るのでcommand injectionが成立する,というドミノ倒しが発生します。もう少しこの「ドミノ倒し」の構造を追いかけてみましょう。

まず,この問題の攻撃要件は「任意の環境変数をセットしてbashを呼び出す」ではなく,「環境変数に任意の値をセットしてbashを呼び出す」です。環境変数名が制約されていればかなり安全なのですが,「どのような環境変数であっても,とにかく問題を引き起こす文字列をセットできればよい」という点がポイントです。これにより,HTTP経由で動作するCGIのたぐいが攻撃の対象として成立します。

HTTP経由で動作するCGIのたぐいは,デザイン上の基本動作として,クライアント(ユーザーのブラウザ)からHTTP経由で引き渡された各種パラメータを,環境変数(たとえばHTTP_USER_AGENTやQUERY_STRING,HTTP_COOKIE)に格納してから呼び出されます。これにより,ユーザーの環境やリクエストに応じてCGIプログラム側の動作を変更することができるという目的です。

この問題が大きなものになるのは,「各種言語からOSの他のプロセスを起動する場合,暗黙で/bin/sh経由で呼び出される」という振る舞いがもうひとつの原因です。CGIから直接bashを呼び出さなくても,CGIから他のプロセスが呼び出される場合,暗黙で/bin/shが利用されるからです。

/bin/shが真にbourne shellやその類似品であれば(少なくともこの件の)問題はありませんが,/bin/shがbashのsymlinkであった場合,本来の「プロセスを起動する」という目的の副作用として「環境変数に任意の値をセットしてbashを呼び出す」という条件が成立してしまうことになります。プログラムの中から他の任意のコマンドを呼び出すことは,Unixのプログラムではしばしば行われることだからです。

……ということで,この攻撃の影響は「/bin/shがbashかどうか」によって大幅に変化するため,readlink /bin/shの結果がbashでないことを確認する,という作業が重要になるわけです。

基本的にUbuntuや現在のDebianであれば,/bin/shはdash注3のsymlinkであり,bashが直接呼び出されていなければこの問題の影響を受けません。ただし,「/bin/shがdashのsymlinkである」は不変の設定ではなく,「sudo dpkg-reconfigure dash」を実行することで変更できます。この変更はほとんどの場合は必要になりませんが,商用ソフトウェア(コンパイラや各種ドライバ)のインストール時に「/bin/shがbashのsymlinkでなければ動かない」シェルスクリプト注4への対応として行われる可能性があります。もしも変更していた場合,/bin/shはbashのsymlinkになっており,「おかしな環境変数が引き渡されるように仕組まれたHTTPアクセスがあると任意のコマンドが実行される」という条件が成立してしまいます注5)。

注3
間違い探しめいていますが,問題があるのは「bash」(先頭がB),Ubuntu/Debianで使われていて問題がないものは「dash」(先頭がD)です。
注4
bash・zsh・kshなどの各種bourne shell派生シェルは伝統的に,/bin/shとして呼び出されると「bourne shellのつもりになって」振る舞うという挙動を行います。この挙動を用いて,/bin/shをbashのsymlinkにしておくことで,純粋なbourne shellを管理せずに済むというモデルが採用されています。しかしbashはzshやkshのような兄弟たちにくらべて「bourne shellのつもり」がいい加減に実装されており,/bin/shとして呼び出された場合にも独自拡張構文を解釈できてしまいます。純粋な/bin/shには存在せず,zshやkshの場合は/bin/shとして呼び出された場合にはエラーにするような構文でも,bashの場合は通してしまいます。結果として,「書いた人間は/bin/sh用のシェルスクリプトだと確信しているし,先頭にも#!/bin/shと書いてあるが,しかしピュアな/bin/shやその正しい互換動作ではクラッシュする」という呪われたスクリプトが生み出されることになります。なお,Debian/Ubuntu環境ではdevscriptsパッケージを導入し,checkbashismsコマンドを実行することでこうした「bashでなければ動かない自称/bin/shスクリプト」を識別できます。
注5
そして人類はこうした問題から自由になれるほどにはまだ賢くないので,「記憶にはまったくないがなぜか/bin/shがbashになっているシステム」が発見されることになります。

著者プロフィール

吉田史(よしだふみひと)

Ubuntu Japanese Team Member株式会社創夢所属。システム管理を中心にWindows/PC Unixを併用している。Ubuntu Japanese Teamではパッケージサーバの管理や翻訳などの作業を担当。

コメント

コメントの記入