パスワードを忘れた? アカウント作成
3223 story

Apacheにセキュリティホール 25

ストーリー by wakatono
影響を受けるマシン、激烈に多数 部門より

MITsu_at_mit-net 曰く、 "多分いっぱいたれこみあるだろうけど。 ZDNN:ニュース速報によると、デフォルトで有効 になっている機能にサービス拒否(DoS)攻撃に対する脆弱 性が存在するそうです。 記事によると、影響を受けるのは1.3.24まで のApache 1.3全バージョンと、2.0.36までのApache 2の全バ ージョンとのこと。 色々作業しなきゃならない人がいっぱい出てきそう。"

Apache.orgからAdvisoryもリリースされている。避ける方法がないだけに、早期のFIX Versionのリリースが望まれる。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2002年06月19日 3時26分 (#109794)
    ざっくり訳してみました。間違いの修正希望。

    http://httpd.apache.org/info/security_bulletin_20020617.txt より翻訳
    Date: 2002年6月17日
    Product: Apache Web Server
    Versions: Apache 1.3 (1.3.24を含む全てのバージョン), Apache 2
    (2.0.36までの全てのバージョン), Apache 1.2 (1.2.2以前の全バージョン)

    はじめに:

    Mark Litchfield氏が、Oracleの脆弱性をテストしている際に、Windows上の
    ApacheにおいてDoS攻撃を発見した。Apache Software Foundationの調査によ
    り、これはもっと広範なもので、あるプラットフォームではDoS脆弱性をもた
    らすものの、別のプラットフォームではリモートexploit脆弱性の可能性をひ
    きおこすものであることが示された。

    我々はまた、本日、ISSから、彼らが同じ件を公表したことを知らされ、この
    勧告の早期リリースを迫られることとなった。

    Common Vulnerabilities and Exposuresプロジェクト(cve.mitre.org)は、こ
    の件にCAN-2002-0392という名前を割り当てた。

    解説:

    Apacheウェブサーバの1.3.24を含むそれ以前と、2.0.36を含むそれ以前のバー
    ジョン2.0、また、2.0.36-devのバージョンは、chunked encodingによりエン
    コードされた不正なリクエストを取り扱うルーチンにバグを持っている。この
    バグは、入念に組み立てられた不正なリクエストをリモートから送られること
    により誘発され得る。この機能はデフォルトで作動可能状態となっている。

    たいていのケースでは、この不正なリクエストの結末は、そのリクエストを取
    り扱っている子プロセスの終了となる。少なくとも、このことは、親プロセス
    が結局は終了させられた子プロセスを取り替えねばならなくなり、無視できな
    い量のリソースを使用する新たな子プロセスを起動することによって、リモー
    トの攻撃者がDoS攻撃を仕掛けることを手伝い得る。

    WindowsおよびNetwareプラットフォームでは、Apacheは、リクエストをサービ
    スするために、マルチスレッド化されたひとつの子プロセスを走らせる。崩壊
    と続く失われた子プロセスを取り替えるセットアップの時間は、著しいサービ
    スの中断をもたらす。WindowsとNetware版は、子プロセスをforkするのでなし
    に、新たなプロセスを生成し、設定を再読込みすることから、この遅延は、他
    のプラットフォームに比べてより著しいものとなる。

    Apache 2.0においては、このエラー条件は正しく検出されるため、これは、攻
    撃者にサーバ上で任意のコードを実行させることを許すことにはならない。し
    かし、プラットフォームは、子プロセスごとに複数のリクエストのマルチスレッ
    ドモデルを使っていることもあり得る(デフォルト設定は、単一スレッドで複
    数プロセス、かつ、プロセスごとにリクエストとなっているけれども、たいて
    いのマルチスレッドモデルは、複数の子プロセスを生成し続ける)。どのマル
    チスレッドモデルを使っても、影響された子プロセスで処理されているすべて
    の同時発生のリクエストは、失われることになる。

    Apache 1.3においては、この件はスタックオーバーフローを引き起こす。32ビッ
    トUnixプラットフォームにおけるオーバーフローの特性により、これは、
    segmentation violationを引き起こし、子プロセスが終了することになる。し
    かし、64ビットプラットフォームにおいては、そのオーバーフローは制御され
    得るもので、そのため、スタックにリターンアドレスを格納するプラットフォー
    ムにとっては、それはさらにexploitableとなるだろう。これは、そのサーバ
    上で、Apacheの子プロセスを走らせるユーザの権限で、任意のコードを走らせ
    ることを許し得る。

    我々は、この方法によりWindows上のApache 1.3がexploitableであることを承
    知している。

    ISSによって提供されているパッチがこの脆弱性を修正しないことに注意して
    ほしい。

    Apache Software Foundationは、この件を修正する新たなリリースに向けて現
    在作業中である。アップデートバージョンについては、こちらを見てほしい。
    http://httpd.apache.org/
  • by nakatomo (8819) on 2002年06月18日 14時54分 (#109418) 日記
    Official Apache Project security advisory [apache.org]によれば、

    1)Windowsと64-bit *nixは、外部から任意のコードが実行される可能性がある。

    2) 32-bit *nixは、任意のコードが実行される心配は少ないが、httpdのサブプロセスが、SIGSEGVで落ちて再起動する。

    ということなので、32-bit *nixでも繰り返しプロセスが落されてDOS攻撃される可能性は残っているそうです。

    ただ、CVSで既に修正(Apache2.0のみ)されているはずのものをISSがバグとして公表したらしく、話がややこしくなっているようです。

    完全には修正できていないらしいのですが、 とりあえずは続報待ちって所ですかねぇ、、、。

    //
    • #企業の事情にもセキュリティ関係にも全く詳しくないので話半分でお願いね

      >ただ、CVSで既に修正(Apache2.0のみ)されているはずのものをISSがバグとして公表したらしく、話がややこしくなっているようです。

      ISS社のFUD?いや、知らんけど。

      以前SNORTにセキュリティホールがあるとの情報が流れた事がありましたが、 [srad.jp]それは現場ではまずしないであろう設定にしている場合に限られるバグであって、報道(?)はISS社によるFUDにすぎないと開発者に喝破されています。

      今回のをFUDというと少々言い過ぎかもしれないけれども、セキュリティ関係の企業としてはこういう情報を流せば点数を稼げるだろうから、バグフィックスの途上であろうとなかろうと遠慮なく公表するんだろうな、と思うのです。

      #ちなみに、「Please note that the patch provided by ISS does not correct this vulnerability. [apache.org]」...ISSが「対策パッチ」を配ってるけど、役立たずだって。ホント?
      --
      gy0
      親コメント
      • ISSが「対策パッチ」を配ってるけど、役立たずだって。ホント?
        ISS 社の Advisory [iss.net] に出ているパッチは 1.3.24 のコードに対するもので、 2.0 には当たらないようです。また、 1.3 でも、 ISS のパッチが修正する場所と Apache Project のほうで CVS 先端で修正している場所は違うみたいです。 ISS 社のパッチで問題が修正されるのかされないのかは知りません。

        Apache 1.3 のほうの修正は src/main/http_protocol.c 1.317 [apache.org], 1.318, 1.319 が関係ありそうです。

        (ちなみに、 2.0 のほうの修正は modules/http/http_protocol.c 1.438 [apache.org], 1.439 だと思います。)

        ぱっとコードを見たところ、バグ自体は単純なもののように見えますが、こういうバグが一つ入り込むだけで弱点になってしまうので、つくづく、サーバを書くのは大変だと思います。

        // ぼくは Apache のコードを真面目に読んだことなどないので、間違ったことを言っている可能性、大です。
        --
        鵜呑みにしてみる?
        親コメント
  • by mass (8786) on 2002年06月20日 20時44分 (#110881)
    セキュリティホールmemo [ryukoku.ac.jp]によると、
    Solaris 6-8 (sparc/x86)、FreeBSD 4.3-4.5 (x86)、
    Linux (GNU) 2.4 (x86)、OpenBSD/i386
    などでも exploit に成功した模様。
    DoS だけか~と安心していた皆様、お気をつけください。
  • by crc (5749) on 2002年06月18日 14時51分 (#109416) 日記
    検証を行った訳ではないので該当しないかもしれませんが
    ここにあるパッチを当てれば解決されるのではないでしょうか?
    http://www.apache.org/dist/httpd/patches/apply_to_1.3.24/proxy_http1.1_chunking.patch
  •  Nimda for ELFみたいなのが出てきそうで、怖いなぁ…。
  • Advisory [apache.org] によれば、「この機能はデフォルトで有効になっている」(This functionality is enabled by default.)そうなのですが、「この機能」って何のことでしょう? httpd.conf で有効にしたり無効にしたりできる何かを指しているのでしょうか。
    --
    鵜呑みにしてみる?
    • アナウンスの内容から引用すると、
      Versions of the Apache web server up to and including 1.3.24 and 2.0 up to and including 2.0.36 contain a bug in the routines which deal with invalid requests which are encoded using chunked encoding. This bug can be triggered remotely by sending a carefully crafted invalid request. This functionality is enabled by default.
      と書いてあるわけですが、まんなかの部分だけをテキトーに訳すと「チャンク形式エンコードされたリクエストが正しくない場合の処理にバグがある。」というところでしょうか。 僕は IIS 4.0の「チャンクエンコーディングされたポスト」の脆弱性に対する対策 (MS00-018) [microsoft.com]あたりに近い話なのかなあ、と思ってるんですけど、チャンクエンコードのことは普段はあまり意識してなかったので、httpd.conf で対処できるのかどうかは、まだ確認してません。
      親コメント
      • ひょっとして、「this functionality」というのは、 chunked transfer coding [w3.org] を使った request を受け付ける機能、ということでしょうか。って、他のコメントをよく読んだら、 #109389 [srad.jp] で zeissmania さんもそう書かれていますね。確かに、 transfer coding という仕様は HTTP/1.0 にはなくて HTTP/1.1 で追加されたのだから、「機能」と呼んでもおかしくはないですね。

        だとすると、 SetEnv ディレクティブ [apache.org] で適切な環境変数 [apache.org]を設定して、 HTTP/1.0 サーバとして振る舞うように強制してやれば、 chunked transfer coding を使った request を解釈しないようになるのかもしれません。 downgrade-1.0 や force-response-1.0 という環境変数を設定すると Apache の動きがどう変わるのかを知らないので、これでうまくいくかどうかわかりませんが。副作用も大きそうですし。

        やっぱり修正されたバージョンが出るまで静観かな……。
        --
        鵜呑みにしてみる?
        親コメント
        • ただ、HTTP/1.1を無効にしてしまうと、
          NameBasedVirtualHostが使えなくなるので、
          ホスティングサイトにとってはかなりイタイと思われ・・・。
          --
          GUST NOTCH な気分でいこう!
          親コメント
          • ただ、HTTP/1.1を無効にしてしまうと、
            NameBasedVirtualHostが使えなくなるので、
            ホスティングサイトにとってはかなりイタイと思われ・・・。
            んでも force-response-1.0 とかした程度だったら別に問題はなくて。
            # どちらにしろ、 agent からは HTTP/1.1 リクエストが送られてきますし

            HTTP/1.0 でリクエストされた時も Host ヘッダさえきちんと付いていれば VirtualHost 処理されますよん。
            親コメント
          • #109581 [srad.jp] を書くときに、 HTTP/1.1 から 1.0 に落とすと一番困るのは何だろうとちょっと考えてみたのですが、 name-based virtual host [apache.jp] は思いつきませんでした(これくらい考えつけ>ぼく)。たしかに、これが使えないと困る人は多そうですね。

            ということで、 #109581 を読んで何も考えずにいきなり httpd.conf に「SetEnv downgrade-1.0」とか書かないように! これで弱点が回避できるかどうか、ぼくにはわかりませんし、副作用はいろいろ考えられます。まさかそんな無謀な人はいないでしょうが、念のため。
            --
            鵜呑みにしてみる?
            親コメント
  • 1.3.26 [apache.org]および2.0.39がリリース [apache.org]されました。

    例の問題はFIXされた模様です。
    急いで入れ替えなければ・・・。
    --
    GUST NOTCH な気分でいこう!
  • by Anonymous Coward on 2002年06月18日 13時55分 (#109374)
    英語が苦手なので私の読み違いかも知れませんが、CERT [cert.org]やApacheFoundationからのAdvisoryを見る限り、目下問題があるのはWin32と64bit-Unixだけのように見えるのですが。。

    # だって1.3.25まだ上がってないから(T-T
    • by zeissmania (3689) on 2002年06月18日 14時09分 (#109389)
      Windows版で、任意のコードが実行されてしまう。UNIX 64bit版で似たようなコードの実行の可能性有り。UNIX 32bitではsegmentation violationが起こる(つまりOSごとクラッシュ?)てことみたいです。
      だからUNIX 32bit版では、乗っ取られることはないんじゃないかと思われますが....。
      それとデフォルトで有効になっている機能(requests which are encoded using chunked encodingを受け付ける機能)を無効にしたらどうなるかが見当たらないのと、httpd.confのどの設定なのかがイマイチよく判りません。
      親コメント
      • Re:影響の範囲 (スコア:4, 参考になる)

        by LightSpeed-J (4514) on 2002年06月18日 14時36分 (#109408) ホームページ
        32-bitUNIXだと、

          >this will cause a segmentation violation and the child will terminate.

        ということな様子。

        全体としては、

        1.3/2.0共に、Windows/Netware/32-bitUNIX/64-bitUNIX なんかだと、
        「処理をしていた子供(微妙)が死亡する」ので、
        「プロセスの上げなおしに資源を奪われ」たり「同一プロセスが処理している他の接続がうしなわれ」たり、しますが、
        1.3で 64bit-UNIXを利用している場合には、「(プラットフォームによっては)のっとられる可能性があります」

        な感じではないのかな?

        全てのケースが網羅されて説明されてるわけではなさそうなので、
        多少微妙なところはある様子。
        --
        -- LightSpeed-J
        親コメント
        • Re:影響の範囲 (スコア:2, 参考になる)

          by tix (7637) on 2002年06月19日 2時56分 (#109791) ホームページ
          1.3/2.0共に、Windows/Netware/32-bitUNIX/64-bitUNIX なんかだと、
          「処理をしていた子供(微妙)が死亡する」ので、
          「プロセスの上げなおしに資源を奪われ」たり「同一プロセスが処理している他の接続がうしなわれ」たり、しますが、
          1.3で 64bit-UNIXを利用している場合には、「(プラットフォームによっては)のっとられる可能性があります」
          Apache Project の Advisory には書いてある内容に従えば、それで合っていると思います。

          ただ、子プロセスが落とされて立ち上げ直す、というのを繰り返したからといって、資源がどんどん減っていくようなことってあるのでしょうか。プロセスを fork するときに一時的に資源を食うだけなら DoS にはなりませんよね。

          それと、 32-bit Unix と 64-bit Unix で何が違うのかもよくわかりません。 #109768 [srad.jp] にも書いた ISS のコメント「ISS X-Force response (fwd)」 [neohapsis.com] には、 32-bit Unix のほうが任意コード実行可能の弱点を exploit しやすそうに見えるが、それでも無理、と書いてあるように見えるので、 Apache Project の説明との違いに驚いています。

          ISS と Apache Project の言っていることはほかにもいろいろ食い違っています。どうしてこんなに違うのか、という点が一番よくわからないのですが……。
          --
          鵜呑みにしてみる?
          親コメント
          • by zeissmania (3689) on 2002年06月19日 14時41分 (#109988)
            >どうしてこんなに違うのか、という点が一番よくわからない
            CNET Japan [sphere.ne.jp]に今回の経緯が掲載されています。
            どうもISSはろくに確認もせずに大騒ぎをした模様。
            親コメント
            • by tix (7637) on 2002年06月23日 15時41分 (#112046) ホームページ
              情報ありがとうございます。

              ISS が今回の弱点について、 Windows 版以外は DoS しかできないという間違った判断をして、悪影響の大きさを考えずに公表したということのようですが、その背後にはもともと ISS が Apache 開発チームを信頼していないということがあるようですね。

              ISS が間違った判断をしたことはともかく、「自分たちの判断が間違っていたらどうなるか」を考えずに公表したのは非難されるべきでしょう。

              しかし、部外者としては、「コードを読んでセキュリティホールを見つける」なんて大変な作業ができる人がそうそういるとは思えないので、 Apache 開発チームにも何とか ISS とうまく付き合ってほしいものだと思ってしまいます。
              --
              鵜呑みにしてみる?
              親コメント
      • by nobichan (4085) on 2002年06月18日 19時12分 (#109577) 日記
        UN*X で、ちょっとプロセスが Segmentation violation で
        こけたくらいでは、普通は OS はこけません。
        親コメント
  • by Anonymous Coward on 2002年06月18日 23時19分 (#109677)
    本家にもありますた
    Apache Vulnerability Announced [slashdot.org]
    • Re:本家のトピ (スコア:3, 参考になる)

      by tix (7637) on 2002年06月19日 1時45分 (#109768) ホームページ
      タレコミ文の後の注釈が ISS に対してかなり辛辣ですね。まあ、見つけていきなり公表したのなら非難されてしかるべきですが。 JPEG 画像に感染するウィルス登場 [srad.jp]の話(本家: McAfee Manufactures Virus Threat [slashdot.org])を参照しているのも興味深いです。

      ISS がなぜ Apache Project に知らせる前に公表したかについては、「噂だけど」という但し書き付きですがこんなコメント [slashdot.org]があります。 ISS と Red Hat が仲が悪く、 Apache の開発チームの中に Red Hat の社員がいるからだとか。

      また、 ISS のパッチで問題が回避できるかできないかについても、少し議論が行われているようです(結局、結論は出ていないみたいですが)。この点については ISS のコメント [neohapsis.com]が参照されており、参考になるかもしれません。この中で ISS は、 Windows で弱点が exploitable である理由を説明しています。また、 ISS のパッチでどうして弱点の exploitation を防げるかも説明しています。もしこれが事実なら、 Apache のチームの言う
      Please note that the patch provided by ISS does not correct this vulnerability.
      という表現は、間違いはなくとも少し誤解を招く表現かもしれません。
      --
      鵜呑みにしてみる?
      親コメント
typodupeerror

長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds

読み込み中...