yohgaki's blog

Link: http://www.isc.org/sw/bind/bind8-eol.php

また別のDNSキャッシュ汚染脆弱性が見つかったBIND8ですが、2007/8/27でメンテナンス終了と宣言しています。

ISC is announcing BIND 8 to be End of Life as of today, 27 August 2007.

ISC strongly encourages users who depend on BIND 8 to migrate to BIND 9 as soon as possible.

djbdnsを使っているので影響ないですがBIND8が残っているシステム管理者の方、ご苦労さまです...

どうせアップグレードするなら別のDNSサーバも検討してみるのも良いかも知れません。

DJBDNS
http://djbdns.qmail.jp/

PowerDNS
http://www.powerdns.com/

MaraDNS
http://www.maradns.org/

Name Server Deamon
http://www.nlnetlabs.nl/nsd/

dents
http://sourceforge.net/projects/dents/

pdnsd
http://www.phys.uu.nl/~rombouts/pdnsd/index.html

Dual DHCP DNS Server
http://sourceforge.net/projects/dhcp-dns-server/

Oak DNS Server
http://www.digitallumber.com/oak/

Zero Calorie DNS Server
http://www.datazygte.com/downloads.html

dnsjava
http://www.dnsjava.org/index.html

Posadis DNS Server
http://sourceforge.net/projects/posadis/

RB DNS
http://sourceforge.net/projects/rbdns/

JDNSS
http://sourceforge.net/projects/jdnss/

CustomDNS
http://sourceforge.net/projects/customdns/

MyDNS
http://sourceforge.net/projects/mydns/

探してみるとたくさんありますね。

Link: http://www.securityfocus.com/brief/578

Honeypotプロジェクトの調査の結果、興味深いというか、予想通りの結果になったようです。

Older versions of the three major browsers for Windows -- Microsoft's Internet Explorer 6 SP2, Mozilla's Firefox 1.5.0, and Opera's Opera 8.0.0 -- were each used to browse the same subset, about 10 percent, of the sites. While researchers have disclosed about twice as many vulnerabilities for Firefox 1.5.0 as for Internet Explorer 6 SP2, the Honeynet Project found no attacks against the browser. Microsoft's Web software, however, was compromised nearly 200 times.

攻撃する人も効率良く攻撃するためにシェアの多いのIEは200回攻撃されたにも関わらず、バグの多い古いFirefox、Operaは攻撃されなかったそうです。

The survey used a large list of 300,000 URLs belonging to about 150,000 hosts, finding that pornographic sites have the highest incidence -- about 0.6 percent -- of malicious sites, but that all categories included some sites that could lead to compromise.

これも予想どおりですがアダルトサイトが最もリスクが高いようです。しかし、全てのタイプのサイトから攻撃される可能性があるとしています。

A fully-patched version of Internet Explorer 6 visited 2,289 malicious sites, none of which managed to compromise the system.

2289の悪意のあるサイトは全てパッチ済みのIEに対して攻撃を成功させることはなかったそうです。

http://blogs.zdnet.com/security/?p=474

にはリモートコード実行脆弱性数のグラフが載っています。Firefoxが断トツです。

Link: http://www.theinquirer.net/?article=41932

「No spyware, adware, malware」としているSkypeですが

Much to his horror he found that Skype kept asking to see all the details of his Firefox software and its plug-ins.

とLinux版ではFirefoxとプラグインの情報を収集している疑いがあるようです。別の情報

http://www.heise-security.co.uk/news/94975

によると

One possible reason to read the Firefox directory is in order to retrieve from there proxy settings as it is done by Skype for Windows with Internet Explorer. This is supported by tests performed by heise Security, in which Skype opened only directories. The only real file it opened in the Firefox directory was prefs.js which does indeed contain the proxy settings. Another reason for Skype to access the user's directory might simply be to check if the user has installed the vendor's Firefox extension.

好意的に見ればプロキシ設定などを参照するためにpref.jsを読み取り、SkypeのFirefox拡張がインストールされているか確認している、とも考えられます。

試しに自分のLinuxのSkpyeでstraceしてみたところ通常の起動時にはfirefoxのファイルを読みにいかないようです。

今のところSkypeからのコメントは無いようですが「No spyware, adware, malware」と宣言するのであれば収集している情報がどのように利用されているか説明すべきでしょう。

ところで、PC版ではBIOS情報を収集している疑いがあるようです。

http://www.theinquirer.net/default.aspx?article=37489

F-Secureのyoutube動画です。ブラウザのバグを利用して何らかのプログラムを実行させるようです。

http://www.youtube.com/watch?v=fm9ikZs5o38

知らないメールのリンクはクリックしてはならない、と言うだけではインパクトが少ないのでこのビデオは役に立つかも。ただ、音が悪いの難点です。

Bugzillaに結構重要なセキュリティホールがレポートされています。

CVE-2007-4538

email_in.pl in Bugzilla 2.23.4 through 3.0.0 allows remote attackers to execute arbitrary commands via the -f (From address) option to the Email::Send::Sendmail function, probably involving shell metacharacters.

CVE-2007-4539

The WebService (XML-RPC) interface in Bugzilla 2.23.3 through 3.0.0 does not enforce permissions for the time-tracking fields of bugs, which allows remote attackers to obtain sensitive information via certain XML-RPC requests, as demonstrated by the (1) Deadline and (2) Estimated Time fields.

http://www.bugzilla.org/security/2.20.4/

によると8/23には修正版が公開されたようです。コマンドインジェクションなので早くアップグレードする必要があります。

Link: http://grasp.coresecurity.com/

遅ればせながらCore Graspのパッチを読みました。超ななめ読みなので勘違いしているかも知れません。間違っていたら教えてください。

一番興味があったのはSQLインジェクションの自動検出はどうなっているのかです。以下の関数がSQLインジェクションチェックに利用されています。

+int grasp_check_query(zval *z)
+{
+	char *c,*s;
+	int i,j,l;
+	char q;
+
+	if (grasp_isfull_p(z)) return 0;
+	if (!grasp_isptr_p(z)) return 1;
+	if (z->type != IS_STRING && z->type != IS_CONSTANT) return 1;
+	
+	
+	l = z->value.str.len;
+	c = z->value.str.val;
+	s = z->secmark;
+
+
+	for(i = 0; i<l; i++)
+	{
+		if (s[i] && (c[i]=='-'))			
+		{
+			i++;					
+			if(!(c[i] < '0' || c[i] > '9')) 
+			{
+				for(i;i<l;i++)			
+				{
+					if (c[i] < '0' || c[i] > '9')
+					{
+						if (!s[i])
+							break;	
+						else
+							return 0; 
+					}
+				}
+			}
+			else
+			{
+				return 0;
+			}
+			if(i == l) return 1;
+		}
+		
+
+		if (s[i] && (c[i] < '0' || c[i] > '9')) return 0;
+		
+		if (c[i] == '¥¥')
+		{
+			i++; 
+			if (s[i]) return 0;
+		} else
+		if (c[i] == '¥'' || c[i] == '¥"' || c[i] == '`')
+		{
+			q = c[i];
+			for(i++; i<l; i++)
+			{
+				if (c[i] == '¥¥')
+					i++; else
+				if (c[i] == q)
+					break;
+			}
+			if (i<l && s[i]) return 0;
+		} 
+	}
+	return 1;
+}

どうも文字列の各文字が安全かチェックして安全でない場合はエラーにしているようです。単純に「この文字列（ZVAL）は関数で処理済みで安全」とマークしている訳でないようです。

ではmysql_real_escape_stringとかを拡張して安全マークを追加しているのかな?と思ったらしていないようです。代わりにaddslashesが拡張されていました。

PHP_FUNCTION(addslashes)
 {
 	zval **str;
+#ifdef HAVE_GRASP
+	char *res, *secm;	
+#endif
 
 	if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &str) == FAILURE) {
 		WRONG_PARAM_COUNT;
@@ -2884,11 +3266,23 @@ PHP_FUNCTION(addslashes)
 	if (Z_STRLEN_PP(str) == 0) {
 		RETURN_EMPTY_STRING();
 	}
+#ifdef HAVE_GRASP
+	grasp_normalize(*str);
+	res = 0;
+	secm = 0;
+	//grasp_setptr_p(return_value, zend_get_parameters_secmark());
+	res = php_addslashes_secmark(Z_STRVAL_PP(str),
+	                             Z_STRLEN_PP(str), 
+	                             &Z_STRLEN_P(return_value), 0, &secm, Z_SECMARK_PP(str)
+	                             TSRMLS_CC);
 
+	RETURN_STRING_SECMARK(res, 0, secm);
+#else
 	RETURN_STRING(php_addslashes(Z_STRVAL_PP(str),
 	                             Z_STRLEN_PP(str), 
 	                             &Z_STRLEN_P(return_value), 0 
 	                             TSRMLS_CC), 0);
+#endif
 }

マルチバイト環境ではaddslashesによる文字列エスケープは厳禁な（SQLインジェクションに脆弱になる場合がある）ので実装的には不十分です。

GraspはPHP用のtaintモードとして紹介されていますが、Perl, Rubyなどの一般的にtaintモード呼ばれている機能と多少異なります。

http://www.cs.virginia.edu/~evans/pubs/infosec05.html

に記載されているようなtaintモードになっているようです。
# この論文もななめ読み

具体的には

$sql = "SELECT * FROM table WHERE id = ". $id;
mysql_query($sql);

の様なコードでも$idが危険な文字列かつ攻撃コードを含んでいれば、エラーになります。つまり、$sql文字列中の$id部分が安全かどうかチェックできるようになっています。

例えば、

if (ereg("[0-9]+", $_GET['id']) {
$id = $_GET['id'];
}

の様にプログラマのミスにより$idが危険な変数になっていても攻撃が回避できます。

完成度が高くなれば通常のtaintモードとは比べ物にならないくらい安全性の向上が期待できると思います。しかし、パッチを超ななめ読みした感じでは実用的になるまでもうしばらく時間が必要な気がしましたが、順調に開発が進めばかなり便利な機能になると思います。
# 現状の実装だど文字エンコーディングがSJIS等の場合はSQLインジェクション
# と誤検出すると思います。addslashesなので元々SJIS等の事などまったく考慮
# されていなくて当たり前です。マルチバイト文字の事は考えてないようですが
# UTF-8ならそれなりに使えそうです。

SQLインジェクションは対策が簡単ですが、XSSは適材適所で対応が分かれるので精度の高い対策は難しいです。しかし、LDAP/XPATH/XQuery等のインジェクション攻撃は基本的にSQLインジェクションと同じレベルで対応可能です。半年後くらいにまたパッチを見てみよう。

Link: http://www.tipotheday.com/2007/08/26/wtf-is-this-character/

右から左に書く機能を使ってファイルの拡張子をごまかす方法は有名です。タイトルのリンク先はUTF-8テキストをアドレスバーにコピー&ペーストするとURLでさえ逆向きに表示される、と言う話。私は知らなかったのですがその系に詳しい方には常識だったのかな？？

コメントに書いてありますがOSXのFirefoxでは逆向きにならないようです。今私もOSXで書いているので後でWindows/Linuxで試してみます。

見え方にもよりますが、URLでも使えてしまうと「釣ってください」と言っているのと同じ状態なっているかもしれません... どう見えるか後で試してみよう...

追記：
リンク先のブログ本文のテキスト先頭に制御文字らしきものもあるなぁ、とソースを見ると英文を反対方向（右から左）に書いているのですね（笑

アドレスバーに制御文字を入れてから入力するとOSXのFirefoxでもLinuxのFirefoxでも反対方向にタイプされていきます。つまり、testと入力するとtsetになります。ステータスに表示されるURLを反対方向から表示するブラウザがあると困りますが、当たり前に反対から表示しそうな気がします... 後で試そう...

Link: http://pc.watch.impress.co.jp/docs/2007/0821/toshiba.htm

仮想環境を使ったり、マルチブートにするとどうしてもHDD容量が必要になります。今のノートPCは160GBのHDDですがかなり手狭です。200GB/7200rpmのHDDもよさそうですが熱そう。

MySQLには文字エンコーディングを変更する「SET NAMES」SQL文が用意されています。（PostgreSQLも同様のSQL文、SET CLIENT_ENCODINGがあります）この機能はSQLコンソールからは使ってよい機能ですが、アプリケーションからは使ってはならない機能です。SQLインジェクションに脆弱になる場合があります。

Ruby on Railsの本を読んでいて、ActiveRecordを説明している部分にMySQLの文字エンコーディングを変更する場合の例としてSET NAMESが利用されていました。アプリケーションからはSET NAMESは使ってはならない事を周知させるのは結構時間が必要かなと思いました。

PHPも5.2の途中からMySQLモジュールにlibmysqlの文字エンコーディング設定APIのラッパー関数が追加されていたりするので、たまたま最近読んだRoRの本だけでなく、多くの開発向け情報ソースにSET NAMESを利用した例が載っていると思います。

ストアドプロシージャだけ使っていれば安全ですが、アプリケーションからDBMSの文字エンコーディングを設定する場合、SQL文ではなく必ず文字エンコーディング設定APIを利用するよう紹介しなければならないです。MySQL4はストアドプロシージャが使えないので、フレームワークなどではエミュレートしています。ストアドプロシージャだけ使って防御している「つもり」で防御になっていない場合もあります。これもフレームワークを使っていてもアプリケーションが脆弱になる良い例ですね。

脆弱性の説明は面倒ですが注意事項は簡単です。「DBMSをアプリケーションから利用する場合、文字エンコーディング設定は必ずAPIを利用する」つまり「SET NAMES（SET CLIENT_ENCODING等も)は禁止」です。

Link: http://gihyo.jp/dev/serial/01/php-security/0008

「なぜPHPアプリケーションにセキュリティホールが多いのか？」をテーマにした技術評論社のブログ風の記事を書いています。

一番新しい

http://gihyo.jp/dev/serial/01/php-security/0008

ですが、自分で防いだつもりのセキュリティホールは実は防いだ事になっていなかった、アプリケーションが多く在りました。というより今でも作り続けられています。原因は「サニタイズ」による脆弱性の回避であるものが多いです。なので「サニタイズ」ではなく「バリデーション」と「適切なエスケープ」によって対策すべきです、と書きたかったのですが「エスケープ」の部分を書いてないですね。バリデーションの時に説明するつもりですが、確かに尻切れとんぼのような感じです。

編集の方からこんな感じなのですがどうなんでしょう？メールが来ていました。

http://b.hatena.ne.jp/entry/http%3A//gihyo.jp/dev/serial/01/php-security/0008

と言う感じで何やら否定的なコメントが多いようです。

最初に

今回は熟練したWebアプリ開発者なら常識のクロスサイトスクリプティング対策の落とし穴を紹介します。

と書いているのですがどうも「熟練のWebアプリ開発者なら常識」としている前提が伝わっていなかった？のか記事自体に問題がある？のか理由がいまいち分かりません。

ブックマークしている方を見るとセキュリティ系で有名な方もいます。初心者向けのブログなのであまり一般受けしないエントリはこのブログの方が多はずです。（と言ってもこちらにもあまり役に立つことはあまり書いてませんが）いまいち理由がよくわからないのでもし知っている方教えてください。