最新

おおいわのこめんと (2006-09)


2006-09-01

[Comp] sarge アゲ @ www.oiwa.jp

ここ数週間ハードだったので体がだんだん追い付かなくなってきたので、 年休を1日とって3連休にした。

かといって1日寝ててもしょうがないので、 懸案だった www.oiwa.jp の release version up を ssh 経由でやることにした。 本当はマシンのある現地に行って作業したくてずっと保留していたのだが、 当分日程取れそうにないし……。 ま、既に2回別のマシンで予行演習をしていたので、 3回目はリモートで行けるという変な確信はあったのだが、 ちょっと怖いね (^^;;

とりあえず、基本的には マニュアル通りにやればいいのだが、今回は何故か dist-upgrade で sendmail の削除を提案されてしまった (えーーっ)。 Sendmail に関しては、Debian team は最近のセキュリティアップデートで リリースに入っていない(将来の導入候補の)パッケージに依存するというヘマをやってしまっているのだが、この影響なのかどうかは不明。とりあえず、キャラクタGUI*1で明示的に追加して解決した。

あとはほぼ問題なく進んだのだが、なんか tdiary の調子がおかしい……と思ったら、FastCGI の自前パッチが巻き戻っていた orz。 Ethereal で通信見るまで気が付かなかった……。

Backports のパッケージの山 (かなり重要なヤツ) も一掃されたし、当たってなかったいくつかの脆弱性*2パッチも当たったし、すっきり。

*1 一般論として curses のクライアントはどう呼ぶべきなのかねぇ。GUI と呼ぶと一般的には画素ベースのグラフィックスをイメージする一方で、CUIというとコマンドラインの行ベースのUIのイメージが強いんだよねぇ。

*2 現実に影響受ける脆弱性は自分で必死に backport してた(例)んだけど、Mod_rewriteのやつとか、自分の環境で発現しないヤツは放置されてたのね。

本日のツッコミ(全2件) [メッセージを送る]

ゆーな [intelのe1000あたりがsarge+kernel2.6.8だと動かなくて、testing(=etch)にdis..]

おおいわ [実はリモートだと怖いんで、カーネルは古いのそのまま使ってたりします :-) 2.4.x までは基本的に自前で mak..]


2006-09-05

[Security] OpenSSL Security Advisory [5th September 2006] (その1)

Daniel Bleichenbacher recently described an attack on PKCS #1 v1.5 signatures. If an RSA key with exponent 3 is used it may be possible to forge a PKCS #1 v1.5 signature signed by that key. Implementations may incorrectly verify the certificate if they are not checking for excess data in the RSA exponentiation result of the signature.

うひゃー。とりあえず OpenSSL は出たけど、他の実装はどうなのかなぁ。 「OpenSSL のちょっと間抜けなチェック忘れ」とも言えるけど、 一方で他に有っても不思議ではないしなぁ……。

Since there are CAs using exponent 3 in wide use, and PKCS #1 v1.5 is used in X.509 certificates, all software that uses OpenSSL to verify X.509 certificates is potentially vulnerable, as well as any other use of PKCS #1 v1.5. This includes software that uses OpenSSL for SSL or TLS.

だそうなのだが、正直「えー、ふつー e = 65537 っしょ」と思ったので、 とりあえず Debian の標準CA証明書群から e = 3 のサーバ証明書を探してみた。

sh-2.05b$ for f in *.pem; do
> if openssl x509 -in $f -noout -text | grep 'Exponent..* 3 '
> then echo $f
> fi; done
                Exponent: 3 (0x3)
Digital_Signature_Trust_Co._Global_CA_1.pem
                Exponent: 3 (0x3)
Digital_Signature_Trust_Co._Global_CA_3.pem
                Exponent: 3 (0x3)
Entrust.net_Secure_Personal_CA.pem
                Exponent: 3 (0x3)
Entrust.net_Secure_Server_CA.pem

うーむ……。4つもあったのか……。 無効化するにはそれなりに広く使われてそうな CA がありますねぇ。 手元ではとりあえず Debian package のアップデート待ち状態。

攻撃の数学的詳細は、186::Diaryさんに 解説されている模様。


2006-09-06

[Security] OpenSSL Security Advisory [5th September 2006] (その2)

(昨日の続き)というわけで、ソース読み読みモード。

OpenSSL

何この汚いソース……。*1

ってこれは前の脆弱性の時にさんざん読んだし、今回もうパッチでてるんで、パス。

gnutls

apt-get source libgnutls11 っと。……何この汚いソース……。

とりあえず SSL の handshake から全部追い掛けました。OpenSSL の修正の箇所にはチェックがないんで一瞬焦りましたけど minitasn1/decoding.c の 895 行に

  if(counter != len){
    asn1_delete_structure(element);
    return ASN1_DER_ERROR;
  }

  return ASN1_SUCCESS;

とあるこのチェックが該当するようですね。というわけで多分OK。

Netscape Security Service

apt-get source libnss3 っと。……ぎゃー、Mozilla 1.7.8 のソースが全部落ちてきたー(笑)。

……何この超読みづらいソース……。(こればっか)

で、延々と追い掛けた結果なんですが、やばいかも……。

security/nss/lib の下、ssl/ssl3con.c の ssl3_HandleCertificate からはフックが掛ってるんだけど、 デフォルトは の ssl/sslauth.c の SSL_AuthCertificate。以下 CERT_VerifyCertNow (cert/certhigh.c)、 CERT_VerifyCertificate、CERT_VerifyCertificate、cert_VerifyCertChain、CERT_VerifySignedData、CERT_VerifySignedDataWithPublicKey ときて……。はぁはぁ。長いぞ。

次は VFY_VerifyData (cryptohi/secvfy.c)。VFY_Begin, VFY_Update 辺りは単に hash なので、VFY_End → VFY_EndWithSignature と来る。RSA だと DecryptSigBlock に来て、PK11_VerifyRecover (pk11wrap/pk11skey.c) でまたテーブル引き。 ここでセキュリティモジュールを取り替えられるようだが、多分デフォルトは NSC_VerifyRecover (softoken/pkcs11c.c) だと思う(弱)。そこから参照されるのが RSA_CheckSignRecover (softoken/rsawrapr.c)で、ここで RSA op と padding 除去までやる。やっと ASN.1 データが取れた。 で、cryptohi/secvfy.c:DecryptSigBlock まで戻って、次が SGN_DecodeDigestInfo (util/secdig.c)。実質的な処理は SEC_ASN1DecodeItem 経由で呼ばれる SEC_ASN1Decode (util/secasn1d.c)。

で、やっと本題の ASN.1 のデコード部分ですが、例によって SEC_ASN1Decoder{Start,Update,Finish} の順に呼ばれるいつものパターンで、DecoderStart は下準備だけ。で、デコーダ中身を全部追い掛けるつもりは毛頭無いわけだが、状態機械の状態は allDone, decodeError, keepGoing, needBytes の4つ。 Finish では needBytes でない事をチェックしているだけなのだが、 Update の #if 0コメントとコードを読むと……。うわっちゃー。

で、ちょっと公開を躊躇したんですが、ここまで追い掛けてから最新のソースを確認しに行ったところ、 8/30付けで HEAD ブランチに修正が登録されている のが1週間前にとっくに公開されてました*2

というわけで、これ以降の nightly build は (多分) 安全で、それ以外は脆弱ということのようです。近々 Firefox 1.5.0.7 が出るということかな。

ちなみに、ietf-openpgp ML への投稿を 読みましたが、公開鍵長が3の倍数 (例えば3072) の場合、186::Diaryさんの説明の通りの方法で「紙と鉛筆」(講演原題での表現: with pencil and paper) で解けますが、そうでない場合も 単純に攻撃データを3乗根取って切り上げればいいだけなんで、必要条件というわけではないようです。

*1 下の2つを書き始めてからバランス取るために書いただけだったりして(笑)。 実際これもあまり綺麗じゃないんだよねぇ。自分でCのソースを綺麗に書く自信もあまり無いんだけどさぁ。

*2 対応 する Bugzilla に登録された bug entry は security バグ扱いなので公開されていないんだけど、コードの修正は割と早く公開されちゃうんだよね。これは前の時にも経験してるんで既知なんだけど、もうちょっとなんとかしてもいいよなぁ。

本日のツッコミ(全3件) [メッセージを送る]

mass [e = 65537 ならとりあえず大丈夫なんですよね?とはいえ、コードの確認は必須ですが……orz。 ]

おおいわ [e = 65537 の証明書は今回の攻撃の影響を受けません。が、1つでも e = 3 の CA を信用していたらダメ..]

mass [今回のこの脆弱性のそもそもの原因は、「n を法とした e 乗根を求めるのは難しい」という RSA での電子署名の安全..]


2006-09-15

[Misc] 平成18(し)202 特別抗告事件 棄却決定

敢えてこういうタイトルにしてみる。……といいつつ、今日の日記の本質はまさにこのタイトルなんで。

今回の最高裁の決定、結果だけは極めて重大なんですが、その実体は 上告棄却ではなくてあくまで「控訴棄却の決定*1に対する特別抗告棄却の決定」……つまり、手続き論なんですよね。 「出すべき書類を出さなかったから受け付けられませんよ、さよーなら」と言う決定の確定であって、 それ以上のものではないわけです。*2

で、今日の僕の感想と日記の主旨を先に書いておくと 「弁護士ふざけんな(被告人保護のロール放棄の観点から)」ですなぁ。 ある意味で、「被告人は酷い弁護人に権利を妨害されても割と手が出せない」というのを 実証されてしまったわけですし、我々一般市民には「地下鉄サリン散布事件の容疑者がマトモな形で 有罪または無罪の確定判決を受ける」という決着を永久に奪われてしまったわけですからねぇ。 いろいろな意味で、社会的にきちんと決着をつけておくべき事件だったと思うんで、 その点でも「ふざけんなー」ですね。

もっともここから下の議論については僕は法の専門家では全くないわけで、間違ってたらごめんなさい、なわけですが。

そもそも控訴趣意書は実質的な控訴の意思表示の文面であって、 実際にも刑事訴訟法で定められたいくつかの限られた許される控訴理由のうちの どの理由で控訴をするかを宣言する書類なわけで、これ出さない控訴手続きはあり得ない。 したがって「意思疏通ができないから趣意書が出せないという」主張自体が 「理由はないけど控訴しました」と言う意味になるんで初めからおかしいんですよね。 というのは、「控訴は理由がないとできない」と刑事訴訟法で定められているわけなので。 また、控訴の申し立てをする人は「被告人」か「弁護士」と定められていて、 今回のケースは後者なわけだから、趣意書は「弁護士が出す」書類である、と言うのも重要かと思います。 被告人と打ち合わせる蓋然性はあっても義務的な意味での必要性はないわけですね。

まして、「書類が出なければ決定で控訴を棄却しなければならない」と明示的に命令されている以上、 極論を言えば東京高裁は今回どんなに被告人を裁いてあげたくても却下せざるを得ない (そうしないと裁判所が法律違反を犯してしまう)状態だったわけで、 訴訟指揮とかそれ以前の問題なわけです。ま、実際はどうしても裁くというのであればなんとか裁くことはできたんでしょうけど……。

そういうわけで、今回の事件、「被告に公判の場での防禦の機会を与えるべき弁護士が超巨大チョンボをやって、 被告人が控訴審を受けるたった一度の貴重な機会を奪った」というのが本質でしょう。 実際の問題として、社会正義とかそういう点は一切無視して純粋な戦術論として考えて、 弁護方針を「なんとしてでも死刑確定・執行は回避する(必要なら死ぬまで引き延ばす)」という点に 置いたとしてもですね、いくらでも言い訳がましいこと書いてでもとにかく趣意書を出してしまえば控訴は成立して、 あとは公判が始まってしまえば、心神喪失を理由に公判停止の申し立てでも何でもできた (それこそ診断書とか出して停止の是非で延々と議論できた)はずなんで、 どう考えてもそっちが正解だったはずなんですが、今回の弁護士の対応は 僕にはやっぱりまったく理解できないです。

あと戦術として、やっぱり棄却理由でも触れられていますが、

同日の裁判所と弁護人との打合せの席上,弁護人は,控訴趣意書は作成したと 明言しながら,原々審の再三にわたる同趣意書の提出勧告に対し,裁判所が行 おうとしている精神鑑定の方法に問題があるなどとして同趣意書を提出しなかった

これも大チョンボでしょうね。自ら「出せないのではなく出さない」というのを 宣言してしまっているわけですから、この時点で敗北決定かと思います。

で、先頭で書いておいた日記の主旨「弁護士ふざけんな(被告人保護の責務放 棄の観点から)」に戻りますが、本来なら「申し訳ございません、私達の判断ミスで 訴訟を受ける機会を失わせ死刑を確定させてしまいました」と関係者に土下座 して謝るような状況だと思うんですけど、こういう状況にしておいてまだ裁判 所批判ですか? と言う点がまったく信用できないわけです。 なにがやりたかったんだろうねぇ……。

さて、残された被告人側の戦術としては、刑事訴訟法 435条の再審理由として挙げられている

  1. 原判決の証拠となつた証拠書類又は証拠物が確定判決により偽造又は変造であつたことが証明されたとき。
  2. 原判決の証拠となつた証言、鑑定、通訳又は翻訳が確定判決により虚偽であつたことが証明されたとき。
  3. 有罪の言渡を受けた者を誣告した罪が確定判決により証明されたとき。但し、誣告により有罪の言渡を受けたときに限る。
  4. 原判決の証拠となつた裁判が確定裁判により変更されたとき。
  5. 特許権、実用新案権、意匠権又は商標権を害した罪により有罪の言渡をした事件について、その権利の無効の審決が確定したとき、又は無効の判決があつたとき。
  6. 有罪の言渡を受けた者に対して無罪若しくは免訴を言い渡し、刑の言渡を受けた者に対して刑の免除を言い渡し、又は原判決において認めた罪より軽い罪を認めるべき明らかな証拠をあらたに発見したとき。
  7. 原判決に関与した裁判官、原判決の証拠となつた証拠書類の作成に関与した裁判官又は原判決の証拠となつた書面を作成し若しくは供述をした検察官、検察事務官若しくは司法警察職員が被告事件について職務に関する罪を犯したことが確定判決により証明されたとき。但し、原判決をする前に裁判官、検察官、検察事務官又は司法警察職員に対して公訴の提起があつた場合には、原判決をした裁判所がその事実を知らなかつたときに限る。

のどれかを理由に再審を訴えるしかないけど、使えるのは 6. くらいしかないよなぁ……。 *3

*1 内容審査の結果の判決ではなくて、手続き違反による門前払いの決定、ということね。

*2 しかも、最高裁は今回、特別抗告棄却の決定理由で弁護人の3点の主張を否定していますが、実際は「念のため検証してみた」という性質で、真の棄却理由は先頭に書いてある「単なる法令違反、事実誤認の主張で抗告できる理由に当たらない。」 (憲法違反でしか特別抗告はできない: 妥当性の審理は高裁の異議審でしか行われない) なんで、実体的には主張の審査をしているとはいえ、少なくともフォーマット上はさらにメタレベルの高い手続き論の領域です。

*3 正直、この条文読むまでは「弁護士総取り替えをした上で、『弁護士が酷かったんで控訴審受ける機会逃したんで、職権で再審認めてくださいよ』とお情けちょうだいモードで訴える」というのはありか(裁判所も超重大事件なので認める余地はあるかも知れない)と思ってたんだけど、実際は再審開始決定に形式的な段階で職権を発動できる余地ってほとんど無いのね……。

本日のツッコミ(全1件) [メッセージを送る]

あたぴぃ [まあ、明らかに弁護士の作戦ミスです。おとなしく控訴趣意書出して二審やって上告して、とやっていれば、ここまで大きな規模..]


2006-09-21

[Comp] “Design Patterns in 1972" (Mark Dominus)

Matz 氏の日記より。そうか、C での OOP ってデザインパターンなのか :-) この例は(当時のスタイルを知っている人には)納得させやすい例だなぁ :-)。

僕はここ8年くらいすっかり OCaml (とスクリプト言語)以外を使わなくなってしまって、 静的型付き関数型言語の世界にどっぷり漬かっているのだが、そうするとやっぱり 世の Design Pattern って OOP 言語、特に C++/Java 風の言語特有のものが多すぎるよなぁ、 と言う違和感をずっと持っていたんで、

"Patterns" that are used recurringly in one language may be invisible or trivial in a different language.

というのはすごく当然、真っ当に聞こえる。 OCaml で書いててもやっぱり再帰しない Visitor とか まったく使わないもんなぁ。 *1

同僚の先輩の高木氏も元々はセキュリティ屋と言うよりは言語屋な方で、 言語屋としての利用言語はご存じの通り Java にどっぷり漬っている人なので、 この辺りで議論始めると終業時間突破して終電まで議論になってしまって 生産性が落ちることこの上ない(笑)(やや誇張)。

ちなみに僕は今でも本職は言語屋のつもりなので、前から興味を持っているの は、"Universal Design Pattern"、つまりある意味で言語非依存なパターンが 現状でどれくらいあるのだろう、ということ。もちろん Mark Dominus 氏の議 論を借りれば、ある意味で言語は Design Pattern を取り込んで行くものなの で、時代に応じてその分類は変わっていくんだろうけど、例えば非再帰な double-dispatch する Visitor のように、むしろ機能的には trivial で、そ れを実現できない別の言語の枠組みに載せるためにパターン化したもの*2 と、Iterator のようにある意味でデータ処理の根本的なやりかたに依存して いて、どのような言語の上でもある程度対応物を(パターンまたは言語機構の 実装上に)見つけられるもの*3 とは、ある程 度主観的に分類できるんじゃないかなぁ、と思っている。客観的になるかどう かは判らないけれど。

*1 一方で、木構造を再帰的に copy する default visitor を継承して、 部分的に特定の条件にマッチする枝だけ置換するような処理は コンパイラとか書いてると出てくるんで、少なくとも Fail-Safe C の 実装の中ではこの部分はパターン化してライブラリ化してあったりする。

*2 言語上 trivial になるときに実装も素直になるもの、といえるかな?

*3 実際、Iterator の処理方法の本質は言 語組み込みでもライブラリでも大きくは変わらないよね?


2006-09-29

[Misc] aptitude update

9面パネル(違) いくらコマンド4つ*1と root パスワード1つとはいえ、管理対象が増えるとめんどくさい。

*1 su, aptitude update, aptitude upgrade, apt-get clean.


大岩 寛 (おおいわ ゆたか) <yutaka@oiwa.jp.nospam ... remove .nospam> .

Copyright © 2005-2014 Yutaka OIWA. All rights reserved.
Posted comments and trackbacks are copyrighted by their respective posters.

記事の内容について (Disclaimer / Terms and Conditions)