マイクロソフト セキュリティ アドバザリ

マイクロソフト セキュリティ アドバザリが出ました。

■Web プロキシ自動発見 (WPAD) の脆弱性により情報漏えいが起こる
http://www.microsoft.com/japan/technet/security/advisory/945713.mspx

man-in-the-middle攻撃らしい。
詳細は調べてないから不明。

■Microsoft Web Proxy Auto-Discovery Name Server Resolution Bug Lets Remote Users Conduct Man-in-the-Middle Attacks
http://www.securitytracker.com/alerts/2007/Dec/1019033.html

プログラミングができないSE

ITproのこんなニュース。

■【IT Service Forum 2007】プログラミング軽視が使えないシステムを生む
http://itpro.nikkeibp.co.jp/article/NEWS/20071127/288167/

開発できないSEどころか、問題解決ができない、つまり、直面する問題の何が原因でどう解決する/できるかがわからない、あるいは時間が掛かりすぎる人が多いのは事実だと思う。

寺嶋氏の提唱が必ずしもよいかどうかは不明だが、プログラムが書けないSEなんてのは、料理の作れない料理長と変わらないと思う。必ずしも全員が料理長の能力を持っている必要はないと思うが(そんなチーム構成は冗長度も構成維持費も高すぎる)、普通のコックはうまい料理と料理に対する熱意、創作意欲、発想力があってしかるべきだし、料理や味のトラブルについても洞察力を発揮できてしかるべきだと思っている。

政治家は少なくとも論理的であるべきだ

政治の話は嫌いなのだが、これだけは書いておきたい。
政治家は、最低限論理性を持つべきだ。非論理的な政治家(屋)が、あまりにも多すぎる。

規律を学ぶ機会を得ることと徴兵制の必要性は、何の関連性もない。
その上自衛隊に入れば規律を守る人間を育成できるかのように言っているが、それにしては痴漢、銃器持ち出し、機密漏洩など多数の問題を起こしている。だったらトヨタにでも就職させた方がいい。

■徴兵制「あってしかるべきだ」=東国原宮崎知事
http://www.jiji.com/jc/c?g=soc_30&k=2007112900035
■東国原知事が徴兵制に賛意 宮崎県民との意見交換会で
http://sankei.jp.msn.com/politics/local/071128/lcl0711282237007-n1.htm

bindに埋め込まれたroot servers

L-root serverのIPv4アドレス変更の話題の中で、[DNSOPS dnsops 320]の話が出た。
それへのreplyとして[DNSOPS dnsops 321]があがったので、ようやく時間を見つけてbindのソースを簡単に追ってみた。

[DNSOPS dnsops 321]で言われてるlib/dns/rootns.cに、以下の文字列が指定されている(ML本文を読み返さずgrepして調べてしまった)。ちなみにこれ、bind-9.4.2のsource treeね。

static char root_ns[] =
:
:
“L.ROOT-SERVERS.NET. 3600000 IN A 199.7.83.42n”

このroot_nsを参照しているのは何かというと、lib/dns/rootns.c中のdns_rootns_create()内である。ここでisc_buffer_init()の呼び出し時の引数として渡している。

isc_buffer_init(&source, root_ns, len);

このようにして、root NSを生成しているのだが、じゃあdns_rootns_create()を呼び出して生成をしようとしている人は一体誰なのか。
bin/named/server.c中のconfigure_hints()関数が呼び出していた。

result = dns_rootns_create(view->mctx, view->rdclass, filename, &db);

名前からも想像してしまうが、hintsファイルつまりnamed.root(named.confで指定可能だからファイル名は違う場合もある)をroot NSとしてzone DBを構築しようとしているわけだ。dns_rootns_create()の第1引数のview->mctxは、指定view(namedではviewという概念がある)のメモリコンテクストだと想像する(想像ね)。namedが管理するviewごとのzone情報は、メモリに蓄積されているわけだから(nsupateが入ると、ときどき.jnlファイルを更新したりzoneファイルに反映したりする)、named.conf中で指定された

zone “.” {
type hint;
file “named.root”;
};

というような設定を含むviewにroot NSの設定ファイルの中身を反映させるというわけだ、と思う。
ところでconfigure_hints()ファイルはどこで呼ばれているかというと、bin/named/server.cファイル中で呼び出しを行っている。

result = configure_hints(view, hintsfile);

指定されたviewにヒントファイル(このファイル名は、そのままdns_rootns_create()の第3引数に引き継がれる)のデータを突っ込むのだが、じゃあroot_nsは一体いつのタイミングで使われるわけ?ってのが、同じくbin/named/server.cファイル中の、おそらく以下の部分。

if (dns_name_equal(origin, dns_rootname)) {
const char *hintsfile = cfg_obj_asstring(fileobj);

result = configure_hints(view, hintsfile);
if (result != ISC_R_SUCCESS) {
isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
NS_LOGMODULE_SERVER,
ISC_LOG_ERROR,
“could not configure root hints ”
“from ‘%s’: %s”, hintsfile,
isc_result_totext(result));
goto cleanup;
}

dns_rootnameは上手に追えてないのですが、static dns_name_t rootをそのまま参照しているだけのポインタだと思われる(それ以外で、どこかで代入されている形跡はgrepできんかった)。
originはこれまた上手に追えていません。上記コードが置かれたconfigure_zone()内の初めの方で、以下のように代入したまま変更のない値を使っている模様。

origin = dns_fixedname_name(&fixorigin);

fixoriginっていうのは、configure_zone()の第2引数zconfigを元にメンバ変数を生成している。zconfigは、さらに呼び出し元であるconfigure_view()の中を見る限りでは、named.conf中の現時点でのviewステートメント中にあるzoneステートメントを指しているんじゃないかしらと仮定。その中でさらにhintを見付け、file指定子を探し、dns_name_equal()に至っている。
dns_name_equalで、両者構造体中のメンバ変数ndataを(attributesメンバ変数なども参照して厳密に)比較しているので、DNS的rootの基準であるdns_rootnameと比較することで「zone “.” { … };」を検出、そうであればconfigure_hints()を呼ぶことにしている、と想像する。

configure_hints()で呼び出されると、さきほど辿ってきた関数群をどんどん進み、最初に出てきたlib/dns/rootns.c中のdns_rootns_create()の中にある、この部分に突き進む。

if (filename != NULL) {
/*
* Load the hints from the specified filename.
*/
result = dns_master_loadfile(filename, &db->origin,
&db->origin, db->rdclass,
DNS_MASTER_HINT,
&callbacks, db->mctx);
} else if (rdclass == dns_rdataclass_in) {
/*
* Default to using the Internet root servers.
*/
result = dns_master_loadbuffer(&source, &db->origin,
&db->origin, db->rdclass,
DNS_MASTER_HINT,
&callbacks, db->mctx);

filenameはnamed.conf中で指定しているヒントファイルだが、これがNULLでなければ、このファイルからroot NSを読み込んでzone DBに突っ込んでいる。
root_nsが使われるのは、else ifの条件にひっかかった場合だ。最初の「isc_buffer_init(&source, root_ns, len);」のとおり、sourceがデフォルトのroot NSのデータを示すオブジェクトとして指定されているので(たぶんね)、dns_master_loadbuffer()でデフォルトのroot serversが突っ込まれることになる。

だから、named.conf中でnamed.root(ヒントファイル)の指定がない場合にはroot_ns[]つまり内蔵されたroot serversデータが使用される。したがって、L-root serverのIPv4が変更される前のbindを使っていて、かつヒントファイルの指定がない場合のみ、L-root serversが古いまま参照され続けてしまうということになる。

あ〜、疲れた…。
てか、これであってるのかしら?(保証なし)

BIND-9.4.2リリース

昨日かおとついに、ISCフォーラム会員限定リリースされていたみたいですが、ようやくbind-9.4.2が一般公開されたみたいです。bind-9.4.2rc2から特に変更はない模様。bind-9.4.1からのバグ修正が含まれるのと、例によってLIBINTERFACEで指定される値の間違い(?)があるので、bind-9.4.2rc1の人はrebuildしなければならない問題がある模様。

■BIND 9.4.2
http://www.isc.org/index.pl?/sw/bind/view/?release=9.4.2