新たに発見された Apache の脆弱性「Optionsbleed」

2017.09.27

Heartbleed を覚えていらっしゃるでしょうか?



Heartbleed は、OpenSSL の機能「Heartbeat」に存在していた脆弱性です。Heartbeat は、サーバーに HELLO などの短いメッセージを送信し、同じ短いメッセージが戻ってくるのを待つことで、接続が継続していることを確認できる機能です。



本来であれば不正な要求は無視されますが、Heartbleed の脆弱性を悪用すると、最初に送信したデータよりも多くのデータを返信するようサーバーに指示することができます。


さらには、他のユーザーの閲覧履歴などの個人データや Web サーバー自体の暗号鍵などの機密データも、メモリ内に置かれていれば返送されてしまう可能性がありました。


セッションの認証、リモートからの実行コマンドの挿入、パスワードの推測などのハッキングは不要です。


攻撃者は、一見普通の質問を何度も繰り返しサーバーに尋ね、毎回返ってくるデータを記録しておき、後でそのデータを掘り起こして有用な情報を探します。

そして今回、これと似た脆弱性が発見されました。



今回の脆弱性は OpenSSL ではなく、Apache Web Server として知られる httpd というプログラムに存在しています (正式名称は Apache HTTP Server Project)。


この脆弱性は、HTTP OPTIONS 要求を行うことによって悪用が可能なため、Optionsbleed(リンク先:英語) と呼ばれています。

HTTP について多少知識のある方は、通常データや Web ページの取得、あるいはファイルや入力フォームのアップロードに使用される GET 要求および POST 要求についてご存知かもしれません。



しかし、その他にも数多くの HTTP 要求タイプ(リンク先:英語) (正式名称は「メソッド」) が存在します。その一部を以下に紹介します。



  • PUT: Web データベースに新しい項目を追加します。
  • PATCH: Web データベースの既存の項目を編集します。
  • DELETE: 指定された項目を削除します。
  • HEAD: GET に似ていますが、本文は省略してヘッダーのみを送信します。
  • TRACE: デバッグ目的で、アップロードされたデータをエコーバックします。

すべての Web サーバーが多くの公式メソッドをサポートしているわけでありません。そこで、次のような特別なメソッドを使用することも可能です。



  • OPTIONS: 特定の Web ページに許可されているメソッドを報告します。

OPTIONS を使用すると、応答されることのない要求によって Web サーバーに負荷がかかるのを回避できるため、ユーザー側はフラストレーションを感じず、サーバー側は無駄な処理をせずに済みます。



OPTIONS メソッドの例を以下に示します。



  $ wget -S --method=OPTIONS https://my.example/index.html
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Allow: OPTIONS, TRACE, GET, HEAD, POST
Public: OPTIONS, TRACE, GET, HEAD, POST
Content-Length: 0
Date: Tue, 19 Sep 2017 14:09:26 GMT
$

ここでは、my.example サーバーが受け入れるメソッドを示しています (Allow: ヘッダーに列記されています)。



この例を観る限り、無害であるように思われます。



しかし、ソフトウェア/セキュリティ研究者の Hanno Böck 氏はそうではないと述べています。

Böck 氏は、Alexa Top 1,000,000 に含まれる Web サイトに次々に問い合わせをして、各サイトでどのような OPTIONS がサポートされていたのかを測定しました。

Böck 氏は、サーバーの一部が次のような破損または文字化けしたような応答を返していることに気付きました。



  Allow: ,GET,,,POST,OPTIONS,HEAD,,
Allow: POST,OPTIONS,,HEAD,:09:44 GMT
Allow: GET,HEAD,OPTIONS,=write HTTP/1.0,HEAD,,HEAD,POST,,HEAD,TRACE

Böck 氏が列挙したものの 1 つは、Heartbleed 型のデータ漏洩を連想させます(リンク先:英語) (下記参照)。



  Allow: GET,HEAD,OPTIONS,,HEAD,,HEAD,,HEAD,,
HEAD,,HEAD,,HEAD,,HEAD,POST,,HEAD,, HEAD,!DOCTYPE 
html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"

多くのオプションが繰り返されており、奇妙で疑わしいだけではありません。Web ページのように見える部分が、サーバーから返されたデータに入り込んでいます (この部分は、通常本体を持たない OPTIONS 応答の中ではなく、HTTP 応答の本体に含まれるべき内容です)。



問題点

文字化けした応答に含まれる漏洩したデータが、Apache サーバーの関与を強く示唆していることに Böck 氏は気付きました (漏洩したデータの中には、Apache 固有の設定のように見えるものがありました)。

Apache の開発者 Jacob Champion 氏の協力を得て問題の原因を追求したところ、非常に不可解な脆弱性であることが明らかになりました。



その前に、この問題の背景を少し説明しておきます。


Apache サーバーを構成するには、サーバーに格納されているコンテンツのディレクトリツリーに .htaccess というファイルを配置します。



それぞれの .htaccess ファイルは、下位の .htaccess ファイルによって設定が上書きされない限り、自身が属するディレクトリと下位のすべてのディレクトリについて、構成オプションを設定します。

この方法を用いた場合、サーバーのディスク全体に Apache の構成設定がばらまかれるというマイナスの影響がありますが、1 つのサーバーと 1 つのディレクトリツリーが多くの異なる Web サイト (「仮想ホスト」) に同時に安全な方法で応答できるというプラスの効果もあります。



仮想ホストが同一組織内の複数の部門で使用されている場合でも、複数の企業が共有 Web ホスティングサービスを購入している場合でも、各ユーザーには固有のディレクトリサブツリーが割り当てられます。

サブツリーの設定は、ツリー最上部の安全なデフォルトに固定することができます。その後、設定を厳格化する必要があれば、ユーザーごとにサーバーの構成を変更できます。

ホスティング会社は、ユーザーごとに 1 台のコンピュータ (または 1 台の仮想マシン) と 1 つの httpd の実行コピーが必要ではなくなります。代わりに、(少なくとも理論上は、) 1 台の高性能サーバーを多数の Web サイトとユーザーの間で安全に共有できます。



.htaccess ファイルで変更できる設定 (これらの設定は Apache では「ディレクティブ」と呼ばれます) の 1 つが、Limits です。この設定はその名の通り、現在のディレクトリツリーで使用できる OPTIONS を制限するものです。


たとえば、次のように使用されます。



  <Limits POST PATCH PUT DELETE>
Deny from all
</Limits>

Web サイトのディレクトリツリーの一部を、ファイルを提供するためだけに所有しているのであれば、このような制限を設けることにも意味はあります。これは、管理者ではないユーザーが管理者としてログインするのを禁止したり、攻撃対象領域を最小化するには優れた方法です。

しかし、ディレクティブで設定した HTTP メソッドのいずれかが適用できない場合、「Optionsbleed」の脆弱性が悪用されます。

「適用できない」とは、そのメソッドがグローバルな httpd 構成ですでに無効に設定されているか、DELETE ではなく DELLETE と入力した場合のように、そのメソッドが実際には存在しない、という意味です。



「これは大した問題ではなく、どこかのログファイルに警告を記録しておけばよい」と思われるかもしれません。「すでに禁止されているオプションを禁止したり、存在しないオプションを無効にしたりするのは時間の無駄で、特に状況が悪化するわけではない」と。

しかし、存在しない (あるいは適用できない) Limit を設定しようとすると、Apache は不要になったメモリを解放します。



しかし、それだけではなく、おそらくは解放されたメモリが Apache プログラムの別の部分に割り当てられ、使用されるようになった後も、そのメモリを参照し続けるようです。

この種の脆弱性は、Use-After-Free (UAF、解放済みメモリ使用) と呼ばれるもので、知らないうちに他人のデータを使用したり、個人情報のコピーやネットワーク経由での送信を誤って実行してしまう可能性があります。

Böck、Champion 両氏によれば、Apache がセキュリティ強化のための .htaccess ファイルを処理した場合に、メモリ管理上の脆弱性が誘発されます。



その後、Apache の全く異なる部分が OPTIONS 要求を処理すると、データが流出してセキュリティを低下させる可能性があります。

これが Optionsbleed という名前の由来です。



Optionsbleed 脆弱性の深刻度

.htaccess ファイルが間違って設定されることと OPTIONS 要求を悪いタイミングで受信することが同時発生しない限り、この脆弱性は悪影響を及ぼしません。

実際、Böck 氏が 100 万台の Web サーバーでテストしたところ、Optionsbleed の脆弱性が発生したのは 466 台でした (統計によれば(リンク先:英語)、対象の Web サーバーのうち Apache を実行しているのは約 40 万台であり、脆弱なシステムにおける発生率は約 0.12% になります)。



とは言え、数多くのディレクトリツリー内の数多くの仮想ホストに対して数多くのドメインをホスティングしているサーバーでは、1 人の悪意のあるユーザーが意図的に自身の .htaccess に無効なオプションを設定し、自身の URL に繰り返しアクセスして漏洩するデータを確認することで、この脆弱性が引き起こされる危険性があることは覚えておく必要があります。

漏洩するデータは、Apache サーバーソフトウェアのメモリに格納されているもので、理論上は他のユーザーやサーバー自体のコンテンツが含まれている可能性があります。



同様に、ユーザーに悪意がなくても、.htaccess ファイルをコピー&ペーストし、前述のように「すでにオフになっているオプションをオフにしても問題はないはず」という理由で冗長なオプションを残しておくことで、すべてのユーザーに影響を及ぼすような問題が発生する可能性があります。



対策

幸いなことに、修正プログラムがすでに公開されています。Optionsbleed の脆弱性を修正するパッチ(リンク先:英語)は、Apache のソースコードサーバーから入手が可能です。



サーバーや Web ホスティングをアウトソーシングする場合は、プロバイダーがパッチを適用してくれるかどうかを確認してください。

残念ながら、本稿執筆時点 (2017-09-19T17:00Z) では、Apache は公式のアドバイザリや最新版の Apache を公開していません。当面は、ご自身でコード変更を適用し、httpd の最新版を再構築する必要があります。

当然ですが、現時点では Apache から公認されていないため、利用可能なパッチが本当にこの脆弱性を修正するのに最善かつ最も安全な方法であるかどうかは判断できません。



したがって、すぐにパッチを適用しない場合には、すべての .htaccess ファイルについて、適用できない設定またはスペルが間違っている設定がないか確認することをお勧めします (目的のある正規の設定が、現行の構成でたまたま冗長になっている場合には削除するべきではありません)。



いずれにせよ、現在のパッチは置き換え、改善、拡張、または廃止される可能性があるため、Apache の次の公式セキュリティアップデートをお待ちください。

引用元

おすすめの記事はこちら