<前の日記(2006-09-05) 次の日記(2006-09-15)> 最新

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


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 (2006-09-08 00:36)

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

おおいわ (2006-09-09 13:25)

e = 65537 の証明書は今回の攻撃の影響を受けません。が、1つでも e = 3 の CA を信用していたらダメ、ということには注意が必要です。
(今気が付いたけど、e = 3 の中間認証局証明書に署名しているルートCAも (ルート自身の e の値に関わらず) 信用しちゃダメって事だなぁ……これは面倒だぞ。)

mass (2006-09-10 01:31)

今回のこの脆弱性のそもそもの原因は、「n を法とした e 乗根を求めるのは難しい」という RSA での電子署名の安全性の根源に、「ただし、e が小さくて、(RSA 暗号の)平文の値の一部を変更してもよい場合は保証の限りではない」という但し書きがあることに、実装者が気づいていなかった、というところなのでしょうか。そもそも、前のほうのパディングに FF が使われているのはこの手の攻撃に備えるためだったはずではありますが、なんだか quick hack という感じで、すっきり安全な気がしませんね。e = 3 ではだめでしたが、それなら e = 65537 では本当に安全なのか、不安が残ります。(もちろん、e = 65537 くらいになれば y^e (mod n) する際に桁があふれるので安全になる気はしますが、どう理論的に保証されているのかが不安です)

[TrackBack URL: http://www.oiwa.jp/~yutaka/tdiary/trackback.rb/20060906 (note: TrackBacks are moderated: spams will not be shown.) ]

大岩 寛 (おおいわ ゆたか) <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)