yohgaki's blog

YouTubeに投稿されていたセキュリティ関係の番組です。

全て英語で字幕などはありません。日本でも同じような番組があるのかも知れませんが、テレビはニュースくらいしか見ないので放送されているのかどうか分かりません。

英国BBCのニュース番組のようのです。

Orthus（コンピュータセキュリティの会社）の方のコメントは全くの正論です。多くの会社はセキュリティ製品を購入することで安全性が確保できると考えて、もっとも基本的な対策であるソフトウェアのアップデートを行っていないケースは少なくありません。コンピュータシステムへの攻撃も進化しているので防御策のアップデートも書かせません。

比較的、最近アメリカで作成されたと思われる番組です。

番組中で「セキュリティ上の問題はネットワークではなくアプリケーションにある」と指摘しています。セキュリティに詳しい方には、ネットワークセキュリティの問題よりアプリケーションの問題の方が大きな問題になっている事は常識です。多くのエンドユーザが同じ認識であるか、は疑問です。

eEyeによるMS Office文書の脆弱性を利用した攻撃の実演です。

頻繁に行われているタイプの攻撃です。知らない方が見るとあまりに簡単に攻撃でき、キーロガーがインストールされる様子は衝撃かも知れません。Vistaでも利用できる攻撃はいくらでもある、と出演している方が紹介しています。出演している方の意図は「Vistaを使っているから、と安心できない」と言いたいと思いますが、この番組を見た方が「Vistaでも危ないならXPのままでも良いか」「VistaとXPのセキュリティレベル同じくらいなのか」と思っていしまわないか心配です。

コンピュータワールドの記事によると普通のサイトがかなり危ないようです。

「およそ1,000分の1の割合で、悪意あるWebページが存在することになる」と、Googleのシニア・スタッフ・ソフトウェア・エンジニア、ニールス・プロボス（Neils Provos）氏は述べている。

Linux/Apacheを狙った攻撃 - 確認方法はmkdir 1で紹介している自動化された攻撃では1月の時点で少なくとも1万サイト以上のごく一般的なサイトがマルウェア配布に利用されていると報道されています。

ある程度予想は出来ましたが、

GoogleのProvos氏が驚いたのは、一般のWebサイトがポルノ・サイトよりも安全とは必ずしも言い切れないという調査結果が出たことだ。「調査を始めた当初は、低俗なWebサイトほど危険だと考えていた。実際、アダルト系のページにアクセスしたときは、悪意あるソフトウェアを仕込まれる危険が若干高くなることがわかった。しかし、ほかのページと大きな差があるわけではなかった」（Provos氏）

には私も驚きました。もやは「怪しげなサイトにアクセスしない」といったセキュリティ教育は意味がなくなってきたと言えると思います。

ある程度予想はしていたので、最近エンドユーザ向けに書いたインターネットを安全に利用するTipsには「怪しげななサイトにアクセスしない」は入れていませんでしたが、実際数値として同じレベル、かつ1000に1つ割合で悪意のあるWebページが存在するのはかなりの脅威です。

2月16日に札幌で行われたJPUG北海道 RUBY札幌 合同セミナーの資料です。

http://blog.ohgaki.net/media/users/yohgaki/PostgreSQL-Performance.pdf

セミナーの際には風邪の為、声がでず、非常に聞き辛かったと思います。聞きにお越しいただいた方には申し訳ないです。

fsync=falseなのでかなり速い事は理解していただけたと思います。（かなりのスピートダウンですがfsync=trueでも速いです）セッションをデータベースで管理した場合などにfsync=falseで運用しても問題ないでしょう。しかし、絶対にデータベース上のデータの不整合は困る場合にはfsync=trueに設定しなければなりません。

とは言ってもfsync=falseの速さは捨てがたいと言う方はUPSを利用すると良いでしょう。UPSを付ければリスクはかなり低減できるので、リスクとメリットのトレードオフで選択すれば良いと思います。

UPSを使っても防げないデータの不整合

• カーネルがクラッシュした場合
• HDDのケーブルが抜けたなど、物理的問題の場合
• 電源が壊れた場合（これも物理的な問題ですが、2重化すればかなりリスク低減可能）
• HDDの冗長化を行っていない場合（RAID組まずにデータ保護の為にUPS使っても....ですが念のため）

等が考えられます。

HDDの冗長化を行っていないサイトのデータベースであれば、fsync=falseが困る訳も無いでしょう。このような場合はfsync=falseでどんどん使ってよいでしょう。

fsync=falseはデータベースサーバ全体の設定なので結局は「ショッピングサイトなどでどんな場合でも受注済みデータが無くなると困る」のような要求があるとfsync=falseで運用できないのでは、とご意見も頂きました。このような場合でもログを別の方法で残す、例えば、メールで送信してしまう、別ディスクにジャーナルとして書き込む、など方法でデータ保存の方法を冗長化していればfsync=falseでも困らないサイトは少なくないと思います。そうは言っても、困る物は困る場合はfsync=trueで利用すると良いでしょう。

データベースに拘らずデータの冗長化を考えると、fsync=falseは強力な武器になります。

# PostgreSQL 8.3ならsynchronous_commit=offに設定してリスク
# を軽減する事も可能です。ところで、別ディスクにジャーナル
# として保存する場合はDBよりも先にジャーナルファイルに書き
# 込み、fsyncを忘れない様に注意してください。
# メール送信する場合はリモートのメールサーバが受け取った後
# にDBに書き込むように注意してください。つまりローカルのメー
# ルキューにいれるのみだとジャーナルのように使えない場合が
# あります。qmailならinjectが正常に終了すればOKだとは思い
# ますがメールシステムによっては高い信頼性を期待できない場合
# もあります。

Adobe Readerのセキュリティフィックスは2008/2/7にリリースされました。

http://www.adobe.com/support/security/advisories/apsa08-01.html

APSA08-01 Adobe RreaderとAcrobat8のセキュリティアップデート公開 02/07/2008

しかし、次の記事によるとこの脆弱性を利用した攻撃は1月から始まっていたとしています。

http://www.cio.com/article/182055/Attacks_Aimed_At_Adobe_Reader_Acrobat_Flaws_Intensify

In January, iDefense noticed that the malicious PDF document was being delivered through malicious banner advertisements.

この攻撃は悪意のあるバナー広告を利用し、バナーにアクセスしてPDFファイルをダウンロードし開いてしまうと、Zonebac（Symantecの名称）と呼ばれるトロイの木馬がダウンロードされるとしています。
# プラグインで自動的に開いてしまう設定のブラウザは少なくない

2006年から既知のプログラムであり、通常のアンチウィルスソフトで検出可能と思われます。トロイの木馬は実行しなければ被害は発生しないので実際に被害が発生したケースは少ないと考えられます。

追記：
整数オーバフローで任意コード実行だそうです。かなり危険度は高いと考えた方が良いようです。上記の記事では観測された攻撃はダウンローダーでダウンロードしただけだった、考えるべきでしょう。少なくともバナーをクリックしたらPDFが表示されたり、表示されかけた方は念入りにシステムをチェックするべきだと思います。もしステルス型のルートキットなら見つけるのはかなり難しいとは思います... 管理者権限で利用していなければルートキットのインストールやシステム関連設定の変更は難しいのですけどね...

PHPのTaintモードパッチです。最近更新されていたようです。

ftp://ftp.porcupine.org/pub/php/php-5.2.5-taint-20080130.README.html

Taintモードはあれば良い程度の機能ですが、フールセーフ機能（フェイルセーフでなくフールセーフ - fool safe）としては便利です。入力バリデーション用のコードは必須ですが、そのようなコードが無い場合やあっても不完全な場合には有用です。

PHP 5.2.5よりCVS HEADとPHP_5_3ブランチ用のパッチを作った方が採用されやすいのですが....

このパッチは関数毎に違うマークを付けるtaintモードなのでかなり大きいです。(+遅い）

脆弱性は意外と単純な所に残っている場合の方が多いです。

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5333

Apache Tomcat 6.0.0 through 6.0.14, 5.5.0 through 5.5.25, and 4.1.0 through 4.1.36 does not properly handle (1) double quote (") characters or (2) %5C (encoded backslash) sequences in a cookie value, which might cause sensitive information such as session IDs to be leaked to remote attackers and enable session hijacking attacks. NOTE: this issue exists because of an incomplete fix for CVE-2007-3385.

これだけだと解りづらいですが以下のURLにもう少し詳しく書いてあります。

http://www.securityfocus.com/archive/1/archive/1/487822/100/0/threaded

Examples:
+++
GET /myapp/MyCookies HTTP/1.1
Host: localhost
Cookie: name="val " ue"
Cookie: name1=moi
+++
http://example:8080/examples/servlets/servlet/CookieExample?cookiename=t
est&cookievalue=test%5c%5c%22%3B+Expires%3DThu%2C+1+Jan+2009+00%3A00%3A0
1+UTC%3B+Path%3D%2Fservlets-examples%2Fservlet+%3B

Read more »

たいした事を書くつもりが無かったので、読んでみたいと思っていただいた方や検索エンジンから見つけて読んでいただける方だけで良い、とブックマークサービスなどに追加するボタンを付けていませんでした。時代が時代なので遅ればせながら付けてみました。
# と言っても自分自身はソーシャルブックマークサービスを利用していません。
# 問題があったら教えてください。

このブログに貼付けたボタン/リンクは、以下のサイトとURLから生成したかURLの情報を参考に作成しました。

他にこれもというサイトがあれば教えてください。リモートのJavaScriptを読み込まないサービスであれば追加したいと思います。

Read more »

追記：
この文章を書いたときに少し意地悪で解り辛いかも、と思った事を覚えています。本当に誤解されてしまっている方もいるので追記します。

私はいつも基本的に能動的なセキュリティ対策を選択するようにお勧めしています。能動的なセキュリティ対策とは全ての入力値の厳格なバリデーション処理であり、出力時に過剰とも言えるエスケープ処理です。いわゆるホワイトリスティングと呼ばれるような対策です。
（過剰過ぎるエスケープ処理はセキュリティ問題の原因になるので2重エンコーディングやエスケープはしないように。念のため）

このエントリの書き方が意地悪な書き方であるのは「ホワイトリストはどう作る?」と題して、その書き方を解説していない事です。しかし、それは実際にXSS Cheat Sheetを読み、理解してもらい、その上で安全なホワイトリストはどう作るか自分で考えて欲しかったからです。

その後にホワイトリストとして作ったチェックが、簡単な変更でブラックリストになってしまう事を紹介したのも誤解の一因でしょう。

ホワイトリストの作り方にはケースバイケースで幾つもの指針が有りますが、最も重要と言える指針は

「許容する入力・出力は必要最低限だけ留め、許容した入力・出力は確実に安全である事を保証し、もし不正な入力があった場合は必ず記録し、必要であればプログラムの実行を停止する」

です。これは私の本でも書いている事です。稀に誤解されるので書きますが「プログラムの実行を停止する」とは入力間違いで実行を停止するのではなく、不正な入力で実行停止する事を意味します。

もう少し具体的に、テキスト出力に対するXSS対策で有れば、出力するテキストの文字エンコーディングが正しい事を検証し、かつ文字エンコーディングに合ったエスケープ方法で全ての特殊文字をエンコーディングする事です。HTMLの属性をユーザが指定可能にするのであれば、その属性に対して許可する値を厳格に定め、それ以外の入力は拒否する事です。同じHTML出力するから、といって同じように取り扱えません。テキストならテキスト、属性ならその属性、スタイルならスタイル、JavaScriptならJavaScript、E4XならE4X、DBMSならDBMS、メールシステムならメールシステムの為の「正しいホワイトリストの作り方」があります。

このエントリであえて「ホワイトリストをどう作るか?」書いていない理由は技術革新の早いWebシステムで具体的なホワイトリストの作成方法を書いても無意味となる可能性があるからです。さらに、一つのシステムについてどのようにホワイトリストを作るか解説しても片手落ちです。それよりも最も防御が難しいXSSの攻撃方法を紹介したXSS Cheat Sheatを参照し、自分で最新の攻撃方法を知った上で自分でホワイトリストの作り方を知った方が何倍も価値があり、時間の経過と共に訪れる情報の陳腐化も防げると考えているからです。

ところで、WAFをホワイトリスト形式で設定してWebアプリケーションの安全性を向上させる事も可能ですが本末転倒です。アプリケーションの入出力バリデーションをホワイトリスト化する方が筋であり、順番が逆です。アプリケーションがホワイトリスト方式でのバリデーションを行えば、WAFなどはブラックリスティングのみで利用しても構わないですし、高価なWAFを購入して速度を落とす必要もありません。簡易WAFと動的フィルタリングを組み合わせる方がコスト的にも合理的です。

PCIDSS（Payment Company Industry Data Security Standard)では「WAFまたはコード監査」をコンプライアンスの必要条件としています。WAF(Web Application Firewall)の利用が認められているのは、コード監査が間に合わないユーザに対する救済措置の意味合いがかなり強いと考えています。

WAFはゼロデイ攻撃からシステムを防御する仕組みとして欠かせません。私もWAFの必要性は認めています。しかし、PCIDSSで「WAFおよびコード監査」の両方を要求していません。PCIDSSを策定したセキュリティ専門家も私と同様にWAFの効果を限定的と評価している事の現れでしょう。（将来的には両方必要要件になるかも知れません。しかし、その場合はWAFの機能要件は緩和される可能性が高いと思います）

コード監査+簡易WAFの方がコストメリットが高い、とする意見に疑問を持たれた方の為に記載します。まずコード監査だけではコストが高く付くケースもあります。例えば、アプリケーション設計自体に問題がありセキュアな設計になっていない場合、コード監査後の修正と検証にWAF導入より多くのコストが必要となる場合があります。

しかし、一旦セキュアな設計+コード監査+簡易WAF（ブラックリスティング方式）でシステム構築を行えば、態々設定ミスがありがちなホワイトリスティング方式によるWAF設定など必要なくなります。ホワイトリスティング方式よるWAFの場合、アプリケーションのちょっとした改修でもWAF設定の修正と設定の検証が必要になります。ホワイトリスト方式のWAFは導入すればOKという物ではなく、常にメンテナンスが必要なシステムです。しかも、このエントリでも紹介しているようなメンテナンス時のちょっとしたミスでホワイトリストがブラックリストになってしまう危険性もあります。

総合的なコストが"セキュアな設計+コード監査+簡易WAF"と"ホワイトリスティング方式のWAF"の導入とどちらが低くなるかはケースバイケースですが、直感的に多くのシステムで"セキュアな設計+コード監査+簡易WAF"の方が長期的なコストは確実に安く、リスクも少なくなる可能性が高い、事が解ると思います。

この追記に対応するエントリも作りました。よろしければこちらもどうぞ。
http://blog.ohgaki.net/-13

以下から元のエントリです。

スクリプトインジェクション（XSS）防止にブラックリストが機能しない事は明らかです。ホワイトリストはどう作れば良いか参考となるリンクです。どう作るか書いておいても古くなる可能性が高いので、どこを参考に作れば良いか参考URLを書いておきます。

以下のリンクの情報からスクリプトのインジェクションがどのように行えるかを参考にホワイトリストを作れば概ね間違いないと思います。

Read more »

2008年1月3日のPHP4.4.8のリリースを持ってPHP4サポートが終了しました。海外では「PHP5へ移行しよう」キャンペーンも始まりました。

私は従来から「PHP5へ早く移行すべきです」と繰り返し勧めて来ました。現在でも全てのオープンソースアプリケーションの開発者は、今すぐPHP5に移行すべき、と考えています。

しかし、新規開発を除き、企業ユーザには今すぐPHP5へ移行すべきだ、と一概にアドバイスできません。3つのお薦めしない理由があります。

• PHP4からPHP5へのマイグレーションはそれほど簡単ではない
• PHP5に移行するとマイナーバージョンアップに追随しないとならない
• PHP5.3のリリースが準備されている

Read more »

GNUCitizenによると

CSRF - It comes very handy. It seams that no matter how much you talk about it, very few pay attention on the problem. And it is not a problem that you can afford to have. And among the XSS issues, which most OpenID libraries have, CSRF (Cross-site Request Forgery) seams to be the most pervasive form of attack.

http://www.gnucitizen.org/blog/hijacking-openid-enabled-accounts

とほとんどのOpenIDのライブラリはCSRFに脆弱だそうです。

tiny problemと書いてありますがとても重要な問題です。OpenIDのようなSSO (Single Sign On）システムが脆弱だとそれを利用しているシステム全体が危険にさらされます。

Read more »