Apache相次いでリリース 24
ストーリー by kazekiri
さくさくupdate 部門より
さくさくupdate 部門より
iida曰く、"Apache 1.3.37、2.0.59、2.2.3が相次いでリリースされた。
どれも1.3.28～1.3.36、2.0.46～2.0.58、2.2.0～2.2.2のCVE-2006-3747への対応がメーンの修正のようだ (2.2.3ではExpectリクエスト・ヘッダーのエラー・メッセージの改善をはじめ、他にもいろいろある)。
この脆弱性は (悪名高い?) Rewriteモジュールのもので、幸いこのモジュールは既定ではインストールされない。明示的にインストールしてしまった場合、最悪で任意のコードの実行が可能になるという。
US-CERTは、この脆弱性をMetric 6.48としている (個人的には、もう少し高そうな気がした)。
タレコミ時点ではmod_ssl、Apache-SSLともに対応版は未リリースのようだ。早急な対応が期待される (Apache-SSLは特に)。"
CVE-2006-3747 対策 patch と CERT脆弱性ノート (スコア:5, 参考になる)
FreeBSD portsに入っているpatch [freebsd.org]をどうぞ。
あと、US-CERTからは、
Vulnerability Note VU#395412 [cert.org]がでています。
Re:CVE-2006-3747 対策 patch と CERT脆弱性ノート (スコア:3, 参考になる)
rewriteルールの中で
RewriteRule fred/(.*) $1
のような書き方が危険なのですね。
RewriteRule fred/(.*) joe/$1
だと、OKだとか。
それはそうと、rewriteモジュールって悪名高かったんですね。
Re:CVE-2006-3747 対策 patch と CERT脆弱性ノート (スコア:3, 参考になる)
http://www.apache.org/dist/httpd/Announcement2.0.html
$1の話は例え話なんだね。他も対象って事みたい。
>If the compiler used to compile Apache HTTP Server has added padding to the stack immediately after the buffer being overwritten, it will not be possible to exploit this issue, and Apache HTTP Server will continue operating normally.
http://www.apache.org/dist/httpd/Announcement2.0.html
って、きっとバッファオーバーフローって事だよな。
> RewriteRule .+ %{REQUEST_URI}.gz [last]
ってのだと、REQUEST_URIにゴミ詰められるとどうなるんだろう？
URI禁止文字の内、明らかに変なのが入っていても環境変数に入っているんだっけ？
RewriteCondで自分でチェックするんだっけ？
後の工程でも「.gz」付けただけなら問題無さそうな気もするけど。
バッファギリギリだと追加したから溢れる可能性あるんだろうか？
ふと、気になってしまった。
「joe/」付だと安全なのは何でなんだろうな？と思ってしまう。
想定より大きいの突っ込んだ時に問題が発生する気がするが、「joe/」だと小さくなるよな。()での$Nのサイズが小さいって話？いや、そんな単純な話じゃ無さそうだね。
とりあえず、アップデートすれば良いんだろうけど（俺は非公開のサーバーでしか使ってないけど）。
mod_rewriteは、やっぱ色々弄り回せる為、使うリスクを考えてしまうな。
[ANNOUNCE] mod_ssl 2.8.28 for Apache 1.3.37 (スコア:4, 参考になる)
From: "Ralf S. Engelschall"
詳しくは mod_SSL本家 [modssl.org]
fixですよね (スコア:1, 参考になる)
にしないと新たに発見されたように読めてしまいます
# ～可能になるという。は、可能になっていたという？
mod_sslは28日付けで1.3.37対応版2.8.28をリリースしたもようです
いまさらだけど (スコア:1)
タイトルだけ見てリリースミスって修正リリース出してるのかと思い、
どうせまた修正あるからとスルーしてました。
そろそろ落ち着いただろうと思って見てみたらそういう話じゃなかった...orz
apache httpdだろ？ (スコア:0, 参考になる)
Re:apache httpdだろ？ (スコア:2, 参考になる)
正確云々に拘るのならば「Apache HTTP Server」の方がしっくり来る様な気がするけど。
>Apache 2.0.59 Released
>The Apache HTTP Server Project is proud to announce the legacy release of version 2.0.59 of the Apache HTTP Server ("Apache").
>
>This version of Apache is principally a security release. In particular, it includes an 'important' security patch to mod_rewrite.
>
>For further details, see the announcement.
http://httpd.apache.org/
Re:apache httpdだろ？ (余談: -1) (スコア:2)
『The Apache httpd server』を意味しますね。
<URL:http://www.apache.jp/docs/misc/FAQ.html#what>
最近はApacheと言えば、HTTPサーバーの名称というより
Apache Software Foundationのイメージの方が
強いのかも知れませんね。自分なんかオッサン
だからかApacheのパッケージ名をhttpdにされると非常に
違和感を感じますが。何でapacheにしないんだろうと。
1.xのWin32 Binary (スコア:0)
1.3.36もなかった様に思いますし……
2.xに移行せず、自前でコンパイルもしない人は、1.3.35を使い続ける事になって、危険な様な……
#つか、2.x(Win32)でURLエンコードされてないCookieが化けるBug、修正されないかなぁ……
Re:1.xのWin32 Binary (スコア:2, 参考になる)
Re:1.xのWin32 Binary (スコア:1, 興味深い)
おぉ、Apache.orgにArchive of public software releases [apache.org]なんて所があったんですね。
情報、有り難う御座います。
www.apache.org/dist/ [apache.org]以下しか探して無かったので見付けられませんでした。
以前あったoldディレクトリも何時の間にか無くなったし……
archive.apache.org/ [apache.org]に移動したって事でしょうか？
#でも、1.3.36の公式Win32Binaryは、結局出なかったみたいですね。
#Security fixじゃないから出なかったって事ですかねぇ。
Re:1.xのWin32 Binary (スコア:0)
使っちゃいけない文字をエンコードしないで使ったら化けても文句は言えないと思うけど。バグってるのは apache じゃなくてそういう cookie を吐いてるスクリプトの方でしょ。
Re:1.xのWin32 Binary (スコア:0)
エンコードしないCGI、大量に出回ってるだろうし。全部直せってのはどうかと。
#サーバOSを変更しろ、Win32なら素直にMS-IIS使えって意見もあるだろうけど(汗)
#つか、Unix版でも、Apache2.0.xの初期の頃は化けてた気がするし、直したのならBugと認識したって事でしょう？#Win32だけ放置なのは、なんだかなぁ。RFC違反って事で、全プラットフォーム問答無用で化けて同じ動作なら、納得も行くんだがねぇ。
Re:1.xのWin32 Binary (スコア:4, 参考になる)
出回っていても2.0系が出てから結構立つんだし、まだ直していないのが問題なんじゃないの？
と言うか、出回っていたって、メンテが終わった奴だろ。メンテが続けられているのならばとっくに直っているはず。
俺は最近は見たこと無いな、日本語クッキーは。
とほほのCookie入門でも
>日本語を使用する際にはそれぞれ、%3B、%2C、%20のようにエンコードして記述しなくてはなりません。
http://pzxa85.hp.infoseek.co.jp/www/wwwcook.htm
と％エンコード必須みたいだぞ。
ネットスケープのクッキーの仕様書はショボイので実際にはどうか知らんが、HTTPヘッダーにエンコード無しで日本語があること自体が変だろ。
>#つか、Unix版でも、Apache2.0.xの初期の頃は化けてた気がするし、直したのならBugと認識したって事でしょう？#Win32だけ放置なのは、なんだかなぁ。RFC違反って事で、全プラットフォーム問答無用で化けて同じ動作なら、納得も行くんだがねぇ。
メンテが終わったCGIを自分でメンテもしないで使い続けようとするのはセキュリティーのリスクも高いんじゃ？
スプリクト言語のCGIでしょ？使い続けたいのならば自分で直せば良いんじゃ？
多くの人が使い続けていると思っているのならばCGIの作者と話しつけて、貴方がメンテしていけば良いと思うけど.....
ところで、クッキーの処理ってunixとwin32で動作変わるの？正確にはHTTPヘッダーの追加の動作だけど。
io周りとか、OS固有の部分をwin32用に対応させているんじゃないの？
で、ちょっとwin32でテストしてみた。
---------
#! ruby -Ks
STDOUT.binmode
print "Content-type: text/html\r\n"
print "Set-Cookie: 日本語だよ\r\n"
print "\r\n"
---------
の結果は
>HTTP/1.1 200 OK
>Date: Sat, 29 Jul 2006 16:57:01 GMT
>Server: Apache/2.0.55
>Set-Cookie: 日本語だよ
>Content-Encoding: gzip
>Content-Length: 20
>Keep-Alive: timeout=1, max=100
>Proxy-Connection: Keep-Alive
>Connection: Keep-Alive
>Content-Type: text/html; charset=shift_jis
もう1回叩いたリクエストはこれ（GETとhostはの所は伏せ字にした）
>GET http://********/test_cookie.rb HTTP/1.1
>Accept: */*
>Accept-Language: ja
>Accept-Encoding: gzip, deflate
>User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
>Host: **********
>Proxy-Connection: Keep-Alive
>Pragma: no-cache
>Cookie: 日本語だよ
と、そのまんま出たぞ。
>print "Set-Cookie: name=日本語だよ\r\n"
に変えてみる。
>Set-Cookie: name=日本語だよ
と
>Cookie: 日本語だよ; name=日本語だよ
が結果。「日本語だよ」もちゃんと残ったまま。
化ける？化けないけど。
>print "Set-Cookie: 日本語=文字化け\r\n"
と変えてみた。
>Set-Cookie: 日本語=文字化け
と
>Cookie: 日本語だよ; name=日本語だよ; 日本語=文字化け
とnameに日本語もOKじゃん（これはIEの実装の話だけど）。
charsetを指定していないとかで、IEとかのブラウザが勘違いしているだけなんじゃ？
httpd.confで「AddDefaultCharset shift_jis」みたく指定しとけば良いんじゃ？
2.0.55で問題無しみたい。今59だろ。「Win32だけ放置」って試していないんじゃないの？
ふと思ったけど、日本語を正しく処理出来るかはブラウザにもよるんじゃ？ブラウザのバージョンにもよるし。
古いバージョンのを使っている奴も入るだろうから、「全部直せ」どころか、もっと難しい「世界中の奴に日本語クッキー対応のブラウザ使わせろ」ってことか？日本中でも無理だろ。
やっぱ、％エンコードするべきなんじゃ？
安定性を考えるとそれがベストだと思うけど。アスキーコードを処理出来ないブラウザは無いだろうから。
Re:1.xのWin32 Binary (スコア:1, すばらしい洞察)
何処からそう言う話が出て来たんでしょうか？ AddDefaultCharsetをoff以外にすると、他の文字コードなベージが提供し辛くなって、不便なだけですし、関係ありません。
#もし、CGI側とWebブラウザ側で異なる文字コードを喋っているのなら、其れはApacheの責任では無いでしょう？
＞2.0.55で問題無しみたい。今59だろ。「Win32だけ放置」って試していないんじゃないの？
いえ、2.2.2(Win32)で再現する所までは確認しています。問題は無くなっていません。
どうやら、Webブラウザに格納されたCookieを見て、化けていないと判断されている様ですが、残念ながら問題は其処ではありません。
Cookieが化けるのは、Apacheから見て送信時ではなく受信の時です。
私は、IEではなく、Gecko系のWebブラウザでしか試してませんので、IEでの結果は知りませんが
仮に、問題のCGIがShift_JISなBBSだったとしてと、投稿者名の欄に「日本語文字列」と入力して投稿しますと
(Gecko系)Webブラウザの「cookies.txt」にS-JISで「日本語文字列」と格納され、此の時点では文字化けは起きていません。
問題は此処から先でして、此の状態で先程のBBSを訪問すると、投稿者名の欄が文字化けを起こしています。
此のまま、投稿者名を変更せず投稿しますと、投稿者名の化けた書き込みが投稿され、当然ですがWebブラウザに格納されたCookieも、文字化けしたもので上書きされる事になります。
と云う事で、Apache2.x(Win32)が受信したエンコードされていないCookieを、CGI等が取得すると内容が壊れている。と云う事です。
1.3.35(Win32)では、問題ありません。確か、Netscape4.xでも再現したと思います。(IEでは知らない)
WebブラウザがApacheに送信した内容の所で止まっていては、問題は発見出来ません。
問題は其の先のCGIで取得する所です。
#何やら「(スコア:4, 参考になる)」なんてモデレートがなされていますが、私からしますと「(スコア:0, 見識が足りない)」と云った感じです。(スコア:-1と迄は云いませんが……)
Webサーバは、クライアントから受信したCookieデータを、サイズオーバーでない限りは、素直に(バイナリ扱いで)其のまんまCGI等に渡してくれるのが良いと私は思うんですけどねぇ。
其処から先の動作は、CGIとクライアントの責任だと思うので。
Cookie に any OCTET を書けるか (スコア:1)
chanbaba さんが気にしていて、#987588 の Anonymous Coward さんが気にしていないのは、HTTP サーバとブラウザ間のプロトコルのレベルで Cookie の値が ASCII に制限されていないかどうか。
仕様を読むと、手順を踏めば、RAW BINARY を流せるように見えます。
ただ、この話が #987588 の Anonymous Coward さんの望みどおりか、ちょっと心配です。私も Cookie の値に quoted-string なんて使ったことがありません。
Re:1.xのWin32 Binary (スコア:1)
あ、本当にバグ報告済みでした。
Bug 13029 - Win32 mod_cgi failure with non-ASCII characters in env var [apache.org]
Win32 環境での環境変数を作成する際にコード変換が入っているようです。
Re:1.xのWin32 Binary (スコア:1)
>何処からそう言う話が出て来たんでしょうか？ AddDefaultCharsetをoff以外にすると、他の文字コードなベージが提供し辛くなって、不便なだけですし、関係ありません。
>#もし、CGI側とWebブラウザ側で異なる文字コードを喋っているのなら、其れはApacheの責任では無いでしょう？
あのー、何処が原因で文字化けするのか分からないのですよね？あれが原因で、ソースのここをこう修正すれば直るとか詳しく認識しているの？
「みたく」とは、「この様にしろ」と言う意味で無い事は解っていますか？
#987147は
>まぁ、CGI側が正しくないのは確かなんだが、Apache1.3.xと挙動が異なるってのと、Unix版では化けないって事で、Apacheに問題が無いとも云えん様な。
>エンコードしないCGI、大量に出回ってるだろうし。全部直せってのはどうかと。
と言っていたから、「CGIを弄りたくない」と言う前提があるので、使っている文字コードをCGIで指定していなければ、指定した方が文字化けし難いと判断して、チェック箇所として提案したら、「不便なだけですし、関係ありません」って何それ。
全然的外れのアドバイスで役に立たない邪魔な存在の様な表現ですよね。
原因が解っているのならば、具体的に述べたり、開発している人達に連絡するなり、自分で修正するなりすれば良いんじゃないの？
「Win32だけ放置」と、「放置されている」と言う認識なんでしょ？
何が引き金になっているか解らないからこそ、Charsetとかの話をしたりするのは当然の流れでは？
CGIを弄らないでCharsetをするには、俺のアドバイスは結構良いと思うけど。
>＞2.0.55で問題無しみたい。今59だろ。「Win32だけ放置」って試していないんじゃないの？
>いえ、2.2.2(Win32)で再現する所までは確認しています。問題は無くなっていません。
>どうやら、Webブラウザに格納されたCookieを見て、化けていないと判断されている様ですが、残念ながら問題は其処ではありません。
IEとapacheの間に串を挟んで、串を通るデータを見てます。
と言うか、HTTPのリクエストとレスポンスのログにしか見えないはずなんだけど....
>Cookieが化けるのは、Apacheから見て送信時ではなく受信の時です。
それを言わないで、Charsetは関係無いとか言い出しているのは理解出来ないよ。
>#! ruby -Ks
>STDOUT.binmode
>print "Content-type: text/html\r\n"
>print "Set-Cookie: 日本語=文字化け\r\n"
>print "\r\n"
>ENV.each do |key, value|
> print key, " => ", value, "
\r\n"
>end
とやったら、
>HTTP_COOKIE => ?u?{?e=?¶???≫?￣
と化けてるな。
>#! ruby -Ku
と
>print "Content-type: text/html; charset=UTF-8\r\n"
を変えたら、
>HTTP_COOKIE => ?u?{?e=?????P; a?\a???a?=a??a-?a??a??
エディタで文字コード変えて読んでも駄目だな。
>#! ruby -Ke
と
>print "Content-type: text/html; charset=euc-jp\r\n"
を変えたら、
>HTTP_COOKIE => ?u?{?e=?・ﾟ??≪=￣; a?\a?＆ca?=a??a-?a??a??
と、1個足りない.....
>#何やら「(スコア:4, 参考になる)」なんてモデレートがなされていますが、私からしますと「(スコア:0, 見識が足りない)」と云った感じです。(スコア:-1と迄は云いませんが……)
>
>Webサーバは、クライアントから受信したCookieデータを、サイズオーバーでない限りは、素直に(バイナリ扱いで)其のまんまCGI等に渡してくれるのが良いと私は思うんですけどねぇ。
>其処から先の動作は、CGIとクライアントの責任だと思うので。
アスキー以外を使うのがおかしいのだしさ。そして、「apacheがCGIに渡すところ」なんて一言も言われてなかったのにこの言われようかよ。
あと、安定性を考えるとやはり％エンコードした方が良いよ。
「他の文字コードなベージが提供し辛くなって」と言う考えがある以上、文字コードの統一が図れていないのだろ。
クッキーはサブドメインや下位ディレクトリーにも流れるし、HTTPリクエストに普通文字コード情報は無いし、ブラウザ側の実装で違ったりするかも知れないだろ。
HTTPヘッダーは環境変数に入れる為に、複数行に別れている奴や同じ名前のヘッダーは加工して入れたりするのだろ？
結論（ー２：アンチM＄） (スコア:0)
#自分じゃ何も試してませんごめんなさい
Re:1.xのWin32 Binary (スコア:0)
どうなるか予想出来ない、という定義で事である事が多いと思いますよ。
Rewrite モジュール (スコア:0)
あるのはどういった点なのでしょうか？
後学のためにどういう点が良くないのか知りたいです。
Re:Rewrite モジュール (スコア:3, 参考になる)