！【緊急】開発言語PHPに“最悪”のセキュリティ・ホール，全ユーザーは今すぐ対処を

自宅鯖でp2使ってるんだけど対処したほうがいいのかな

またPHP出版か！！！

>>165
コバルトRaQ550(PHP4.0.6)なら下記の手順でアップグレード可能っぽい

[RAQ550の場合下記の準備をする]
・/usr/lib/apache/libphp4.soをlibphp4.0.6.soにリネームする
・/etc/admserv/conf/httpd.conf内のlibphp4.soの記述をlibphp4.0.6.soに書き換える

・/usr/local/src/ に最新のPHPのtarをダウンロードする
・php-4.3.11フォルダを作成し解凍する

・configureコマンドを実行
・make install
・/etc/rc.d/init.d/httpd restart

(念のためphp.iniを確認する)
完了

うちのRaQサーバーで4.3.11にしたときはこれでいけました

常時age

漏まいら、そんなに心配ならhttpd chrootしれ

>>166
踏み台にされてしまうかもしれんから
直すのがよいと思われ。

特にp2はPEAR使ってるし

なんか違う気もするけどソースはたぶんこれだな
ttp://www.cobaltqube.org/ml/archive/coba-d/20030202.week/5107.html

共用サーバーで開発している方々はどうするんかね・・

age

共用サーバ（WebARENA）でregister_globals=onなんだが、$GLOBALSは使ってない。
これってどう対処したらいいんだ？

>>174
suite2ならPHP自体をアップデートするらしいから放っておけば。
さっき案内が来たよ。

xoopsはどうすれば？

>>175
それで安心してしまうとｱｶﾝような気がするね
次のセキュリティホールが見つかったとき・・

>>175
ほんとだ、ｻﾝｷｭ

>>178
でも、どのみち新バージョンに合わせて全スクリプトの精査しなきゃならんけど…orz

>>159
試したよ。
望みどおり、multipart/form-dataなRequestだけ排除できたよん。
これで、ソース書き換えの間の時間稼ぎになればと。
ありがとうございました。

>>168

うわっ、こんなに懇切丁寧なレス頂くとは。
現実逃避の為に一日中開発に没頭してましたが重い腰あげてみます。
でもうちってテスト環境もねーからとりあえずraQ550もう一台確保するところからっス。
orz
でも情報感謝です。
ほうとに(・∀・) ありがとう!!

age

うちのとこは今日はソースの書き換えを行って、明日から二日間でテスト。
まあ、半日もあれば終わるだろうけど。ちょうど休みの間の平日で通常業務も少なかったから
運がよかったみたい。

出版社じゃないのか

age

けっこういるんだな。
おれはバージョン上げたときに全部書き直しておいた。
メンテが楽だからと当然のように主張したぞ。あり組自慢。

だいぶ落ち着いてきたかな？

この土日がなくなった人、手を上げて〜　　ﾉｼ

(´・ェ・｀)ﾉｼ

t

意味わからん。
俺にはきっと関係ない。
１しか読んでないけど

こういうのってここに載せるような記事なわけなんだろうか?
しかも下がってるのを>>1がアゲるのもどうかと思うよ。

redhat9用にrpm作ってくれないかな。

Java の方が扱いやすいよ。PHPって生産性よくない希ガス。

PHP文庫でﾊｧﾊｧしながらオナホでフィニッシュする俺は最悪ですかそうですか。

セキュリティに対する危機感持ってるヤツ少ないな
みんな個人情報とかは扱ってないのかな？

>>193
JDKビルドの際になぜか必ずコンパイルエラーが出る。

CPUがP54C-133なのが問題なのかっ！

うちのサイトのアクセスログみるとp2から来てるのが
結構居るんだよな。
おまいらちゃんと対策しておけよ

とりあえず、PHP 4.4.1にあげた。
でもregister_globals=onなので、スクリプトもなおしていかないとな〜

これってOSX標準のPHPも影響あるんだよ・・・ね？

3.3.11パッチあてるか4.4.1にまで上げたのならregister_globals=onでも良いんじゃねーの？

>>200
そうね、でも4.4.1はメール周り（mb_send_mail, mb_encode_mimeheader）がダメ
4.3.11用patchは未検証と、悩ましいよね

今のところ問題は出てないようなので4.3.11+patchが正解かな？
誰か当てて問題なく運用しているっていう人いる？

確かPHP 4.3.11 には mb_detect_encoding/mb_convert_encoding に問題があったはず。

[PHP-users 25298]
ttp://ns1.php.gr.jp/pipermail/php-users/2005-April/025814.html

PHP 4.3.11にするなら、ついでにこの問題に対するpatchを適用しておいた方が安全かも。
ttp://cvs.php.net/diff.php/php-src/ext/mbstring/libmbfl/mbfl/mbfilter.c?r1=1.1.2.6&r2=1.1.2.7&ty=u

>>202
はぁ、複雑すぎよね。安心して使えるバージョンはまだかな。。。

じゃあ4.3.11を利用するときには、
今回のセキュリティホール用パッチとmb_(detect|convert)_encodingパッチを当てて利用ってことで。

4.4.1まで上げて、mb_send_mailまわりは自力変換かjcode.phpあたりでラッパー関数作るか。
4.4.0から定数参照の仕様が変わったとかもあるんだっけな、参照引数に直接値渡してないか
全部調べるのめんどくせーなぁ…
標準関数なんてどれが参照渡しなのか把握してねーよ…

mb_send_mail 、うちでは大丈夫だったなぁ。

これがだめだった。
$subject = i18n_mime_header_encode(mb_convert_encoding($subject "JIS", "EUC-JP"));
mail($mail_to, $subject $honbun, $mail_from);

なぜか subject が ISO-2022-JP じゃなく UTF-8 になってた。

4がでても、mbまわり不安だったので、今だに3.0.18-ja のままです。

4.4.2 Devってどこにある？

初心者向けで分かりやすい
http://www.pahoo.org/e-soul/webtech/php01/php02-01.shtm

しかしなんだな、
ニュー速にはプログラマが多いと言うことか？

逆にWebProg板はこっちに誘導するようなクズばっかなんだよな

まずいバージョンでregister_globals=onで、
複数の企業がユーザのサイトだけど、
こんな問題放置だよ。
だって修正費用安いから。
一度全データハッキングされねえかな？と思ってるんだけどな。

(ﾉ∀`)ｱﾁｬ-今知った
register_globalsはOffだったけど、
本家だけじゃなく日本PHPユーザ会もお参りしないとダメですね。
Cの頃は結構グローバル使ってたよ。

オープンソースとか、名が知れたスクリプトを使ってないサイトじゃ、攻撃するにしても変数名一つ探り当てるにも膨大な手間と推理が必要じゃね？
実際のとこ、自分で書いたスクリプトだったらまず安心だな。

http://ns1.php.gr.jp/pipermail/php-users/2005-November/027861.html
これに対してエラい人が「間違ってる」って言わないってことは

>この結果を見る限り、（register_globals=offを前提で）プログラム
>中で$GLOBALS配列を使っていない限り、影響は受けないのかなぁ。。。

これは的を得てるってことなんかな？

大垣氏が公開してるって･･･
会長がパッチ作るユーザ会って廃れてる印象すら受けるな