PHP-4.3.7以前にリモート脆弱性発見 68
ストーリー by koyhoge
さぁバージョンアップ祭だ(涙) 部門より
さぁバージョンアップ祭だ(涙) 部門より
7/14に発表されたセキュリティ勧告「PHP memory_limit remote vulnerability」によれば、--enable-memory-limitで作成されているPHPに対してデータをPOSTするだけで、任意のコードを実行できる脆弱性が発見された模様。 PHP実行プロセスのメモリ使用量を制限するmemory_limit機能のバグをついたものだ。対象となるPHPのバージョンは
- 4.3.7以前のすべてのバージョン
- 5.0.0RC3以前のすべてのバージョン
PHP-4.3.8のリリースアナウンスには詳細が述べられておらず、ChangeLogにも重要性を示唆する言葉は全くないので注意が必要だ。
koyhogeによる追記: 「標準設定のPHPに対して」と書きましたが、4.2.0以降は --enable-memory-limitはconfigureの標準設定では無効になっていました。お詫びして訂正いたします。なお各ディストリビューションが作成しているパッケージでは有効になっている場合が多いので、充分に注意して下さい。
一応隠蔽はしていないと思う (スコア:2, 参考になる)
This release is made in response to several security issues hat have been discovered since the 4.3.7 release. All users of PHP are strongly encouraged to upgrade to PHP 4.3.8 as soon as ossible.
と書いてあるので、まったく触れていない訳ではない様ですが
確かに強調が足りないとは言えますね。
『今日の屈辱に耐え明日の為に生きるのが男だ』
宇宙戦艦 ヤマト 艦長 沖田十三氏談
2006/06/23 JPN 1 - 4 BRA
Re:一応隠蔽はしていないと思う (スコア:3, 興味深い)
とはいえ、安心というわけではないらしい (スコア:3, 参考になる)
Redhat9は、該当のコンパイルスイッチがONになってます。
FedoraCore2は、該当のコンパイルスイッチがONになってます。
ご注意ください。
MacOSX10.3.4Serverは、該当のコンパイルスイッチはありません。
#これで、コンパイルスイッチ関係なかったらある意味道化だなぁ
Re:とはいえ、安心というわけではないらしい (スコア:1)
どうやらOFFになっているようです。
$grep enable php.spec
で見てみたんですが、見落としてますかね?
Re:一応隠蔽はしていないと思う (スコア:2, 参考になる)
--enable-memory-limit (スコア:1)
記事本文を修正しておきました。(まだ調べが足りなかった…)
Gentooの dev-php/mod-php では (スコア:2, 参考になる)
'--disable-memory-limit'
になっていました。
USE="memlimit"でON/OFFするみたいです(未確認
---にょろ~ん
Re:Gentooの dev-php/mod-php では (スコア:1)
# IDでも二分制限あったんだ・・・
---にょろ~ん
Re:--enable-memory-limit (スコア:0)
裏を返すとそれ以前ではデフォルト有効ですね。
Re:--enable-memory-limit (スコア:1)
Re:一応隠蔽はしていないと思う (スコア:1, 参考になる)
Re:一応隠蔽はしていないと思う (スコア:0)
4.3.x のダメダメ具合が怖くて使えないので 4.2.x にバックポート求む。
Apache 1.3系を除くApache 2.0.49以前の環境で問題 (スコア:2, 参考になる)
Apache 2.0.49で発見されたCAN-2004-0493の問題は32ビット環境において軽微だと見なされていたが、4.3.7以前のmod_phpにmemory-limitが組み合わさっているとまずい。
という話であって、
最新のApache2や、Apache 1.3などApache2以外の環境で使っている場合は問題ないと思うのです。
みんな原文読んでいる?
Re:Apache 1.3系を除くApache 2.0.49以前の環境で問題 (スコア:2, 参考になる)
NON Apache 2 でも動作する同様の攻撃方法が見つかったって書いてあるじゃないですか。
だから Apache 2 以外でもだめでしょ。
以下アドバイザリの該当部分:
After a possible exploitation path for Apache 2 servers was discovered and a working exploit was created, similar pathes were found and added to the proof of concept exploit that allowed exploitation of NON Apache 2 servers. (f.e. Apache 1.3.31)
Re:Apache 1.3系を除くApache 2.0.49以前の環境で問題 (スコア:0)
英語読めません。
折角だから (スコア:2, 参考になる)
いまだに (スコア:1, 参考になる)
アップデートしたいのは山々ですが、PHPの各バージョン
間の互換性のなさには辟易していますので、手が出ません。
PEARを使って書いたページが、PHPのバージョンアップで
全て使えなくなって、泣いたことがあります。
4.3.xのマイナーバージョン間ですら、この程度の互換性
ですから、5.xなどまず手を出したいとは思いません。
Re:いまだに (スコア:1, すばらしい洞察)
全てを捨てて5系に旅立つという考えもありかと
Re:いまだに (スコア:0)
Re:いまだに (スコア:1)
>全て使えなくなって、泣いたことがあります。
これって、本当なんですか?
だとしたら、いまだにPHPLIBを使った方が、
互換性は高いって事でしょうか?
PukiWiki (スコア:1)
今回ので4系でもアウトになる・・・なんてこたあまさか無いよなあ・・・。詳しくチェックしてないです。
Re:PukiWiki (スコア:3, 参考になる)
PukiWikiはもともと、クラスの使い方がおかしいため(PHP4では、うごいちゃってた)オブジェクト指向周りを書き換えたPHP5では動かないって話です。
今回の修正点を見る限り、php 4.3.8でちゃんと動くと思います。っていうか家で動いてます。
PHP5ではどうがんばっても完全に動かすのはだめでした。
PukiWiki1.5もしくは2.0に期待しましょう。
アップデート作業状況 (スコア:1, 参考になる)
隠蔽 (スコア:0, フレームのもと)
> ChangeLogにも重要性を示唆する言葉は全くない
無責任なことですね。透明性が命のオープンソース
プロジェクトで隠蔽まがいのことをするなんて。
隠してないよ。あんたら英語が理解できないだけ (スコア:3, 参考になる)
つもりだったのだろうが、第三者がソースのどこが変更されたかを見て、 それより先に問題を暴露したのだろう。
# PHP 4.3系でメンテナンスリリースが出るとすればセキュリティー修正のためである事は明らかだから
隠蔽だって? 何を言っているのだか。じゃあ「こうすりゃ任意のコードが実行できる」と開発チームからいきなり exploit でもオープンにして欲しかったとでも言うわけ?
ジャイアン (スコア:1)
この精神にのっとり、
全ての情報や PG が必ず自分の物になると信じているのです。
OpenSource に何一つ、貢献しなくても、
みんなが自分の為に働いてくれると思ってしまうのです。
そっとしておいてあげて下さい。
どうしてもと言う時は、
「サポートがついている商用のプロダクト買えば。」
と、優しく教えてあげて下さい。
優しくですよ。
じゃないと、ヒステリーから泡を吹いて倒れちゃいます。
本当は良い子なんです。
優しくしてあげて下さいネ。
オフトピから本題へ(Re:ジャイアン) (スコア:2, おもしろおかしい)
何の略称か伝わっているみたいですが、確かに変な略称ですね。
HP と言えば電卓会社の事で、
Home Page では無いし Hit Point ではないよね。
# 最近、電卓作ってるのかな ?
CG と言えば Car Graphic だよね。
# 昔はね。
これから気をつけますね。
で、君達は「クレクレ君」にどう対処するのが良いと思うんだい?
Re:オフトピから本題へ(Re:ジャイアン) (スコア:1)
> しろという立場をクレクレ君と言ってますか?
言うだけで、何も行動しない(しかもモチベーションを下げる)人を
「クレクレ君」と言ってます。
「セキュリティ情報をしっかり開示し、影響範囲や重大性を明らかにしろという立場」
に立っているかのように自分を誇張して、実は悪口を言うだけの人でも良いかな。
きっと Change Log ではなく Security Alert が欲しいんだと思うんですよ。
でも、おねだりの仕方がなんとも下手。
「隠蔽だ」とか「重要度の表示がない」とか、
陰口たたいてないで、自分が望んだ世界になるように仕組みとか作って下さい。
1. こんな風に情報を出して欲しい(FreeBSD-SA-04:03.jail.asc [freebsd.org])
2. FORMAT はこのままパクれば OK だろう。
3. コネがないから PHP-users の偉い人に相談してみよう。
ぐらい行動を起して始めてようやく、あなたの言う立場に立てるのではないでしょうか。
それまでは、ただのノイズ(クレクレ君)でしかないでしょう。
Re:オフトピから本題へ(Re:ジャイアン) (スコア:1)
どの辺が、建設的な意見なんでしょうか?
手は動かさないが、口は出す。
で、それは奨励されるべき。って事ですよね ?
Re:隠してないよ。あんたら英語が理解できないだけ (スコア:1)
OepnSSHだかなんだかで そんな感じの発表方法で 反感買ってた人がいたような気がしますなぁ.
それを考えると あまりお馴染の方法とか言わない方がいいような気がします:-p
それから exploitを出さないと隠蔽ってことではなくて 『こんなsecurity holeがあったよ』ってことを前面に出してないってことを言ってるんじゃないですかね.
僕も隠蔽だとは思わないけど, そこら辺話が噛み合わないのはちょっともったいないですよ.
Re:隠してないよ。あんたら英語が理解できないだけ (スコア:0)
まあ、いつも、作っている側は、ユーザは簡単にアップデートできるはずだと思っているんですよ。自分たちはすべてを把握しているからね。「常に最新版をお使いください」ってわけさ。
Re:隠してないよ。あんたら英語が理解できないだけ (スコア:2, 参考になる)
オープンソースソフトウェアの中の一部がプロプライエタリなソフトウェアの一部よりも「バージョンアップに伴うソフトウェアの挙動の変化」をより軽視しがち、という話なら同意できます。
つか、「動作環境」としてそういうことに気を使っているのはdebianのstableくらいだと思います。SPやHotFixの適用後に、時として自社のアプリすら動作がおかしくなったりすることがあるMSは、確実に同様の問題を抱えていると言えます。
オープンソースか否かはあまり関係ないのではないかと。
Re:隠してないよ。あんたら英語が理解できないだけ (スコア:2)
> debianのstableくらいだと思います。
確かに一昔前まではそうだったかもしれないが、RedHat Enterprise
LinuxやSuse Enterprise Serverが登場してからは、そうとは
言えない。
データベースをはじめとする商用製品のプラットフォームとして
重要な役割を果たしつつあるだけに、動作環境への配慮は
debian以上にされているみたいだ。
Re:隠蔽 (スコア:2)
php-4.3.8 は Security Fixes release であり,
PHPの利用者は出来るだけ早く4.3.8にアップグレードすることを
お勧めします.
とありますので,隠蔽まがいではないと思います.
Re:隠蔽 (スコア:1, おもしろおかしい)
Re:隠蔽 (スコア:0, 余計なもの)
Re:隠蔽 (スコア:1)
PHP [php.net]のトップページにも明瞭に書いてあるし、ChangeLogからもすぐに読める場所に、
"Security Fixes release" とか、
"All users of PHP are strongly encouraged to upgrade to PHP 4.3.8 as soon as possible."
とか書いてあるので、セキュリティ関連が原因でできるだけ早くアップデートする必要があることがすぐに分かります。
具体的にどういう問題があったのかは、よく調べないと記述がない点はよろしくないですが、このアップデートの「重要性は十分に示唆されている」と思います。
Re:隠蔽 (スコア:1)
目立たなかった原因の気がします。
修正版だけがリリースされていれば隠蔽という印象はなかったはずです。
-- http://catbot.net/
Re:隠蔽 (スコア:0)
釣られすぎ。
Re:隠蔽 (スコア:0)
ちと言い過ぎですよ。
相手方のやる気を削ぐような物言いをしてもしょうがないんです。
少なくともここでアナウンス(コピペだが)したんだし。
# さあ、俺の自宅鯖もアップデートだ。
Re:隠蔽 (スコア:0, フレームのもと)
> プロジェクトで隠蔽まがいのことをするなんて。
オープンソースプロジェクトに責任を求めるんですか?
もしかしてフランス [srad.jp]の方?
#本意ではないが思いついたので発言してみる
やなぎ
字面じゃなく論旨を読もう。モデレートはそれからだ
Re:隠蔽 (スコア:1, 興味深い)
PHPのように広く普及していて、しかもコミュニティが自ら積極的な普及活動もしているようなソフトウェアにおいては、バグが見つかったら誠実に対応、修正し、正しく告知する社会的な義務があると思うべきだと思います。
でないと、利用者(間接的なユーザも含む)が困るのはもちろんのこと、「オープンソースは、ソフトウェアは無償だし、コミュニティもボランティアベースだから信用できない」という偏見を乗り越え、覆してきた歴史に逆行することにはならない?
今回の件が無責任とまでは思わないけどね。
(あ、「無償」の部分についての無粋なツッコミはやめてね)
だれか助けて・・・ (スコア:0)
#トラブルだらけで一杯一杯のところに、勘弁してほしい。もう限界。
#何台サーバのアップデートしなければならないんだろう。4.2のサーバもあるので動作確認も含めるとかなりヤバい。
#2週間ぐらい延命できれば手が開くのだが・・・。
Re:だれか助けて・・・ (スコア:1, 参考になる)
もう誰も使ってないって? (スコア:1, 参考になる)
Re:だれか助けて・・・ (スコア:0)
他に同じ悩みを持ってる人も救われます
Re:だれか助けて・・・ (スコア:0)
どこの馬の骨とも知れないACだから助けようがないね。
#マヂにとられてホントに連絡くるとまずいので自分もAC
Re:だれか助けて・・・ (スコア:0)
# killall httpd
はい、万事解決です。
折角だから
# init 0
しておくのも良いですね。
-----
セキュリティに近道はありません。たとえそれが困難な道でも進まねばならないのですから。
apacheの問題? (スコア:0)
PHP 4.3.8は、apacheにapacheに対するパッチが当たってなくても大丈夫なようにするための物な気もします。
Re:重要性を示唆する言葉は全くない (スコア:0)