<前の日記(2004年12月19日) 次の日記(2004年12月25日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 1179   昨日: 3744

2004年12月21日

バージョン番号くらい書こうよ

JVN#B4BE09A4 が発表された。

影響を受けるシステム
- Shuriken Pro3
- Shuriken Pro3 /R.2
- Shuriken Pro3 /R.2 [ベリサイン セキュリティメールセット]
- Shuriken Pro3 Corporate Edition

JVN#B4BE09A4: Shuriken Pro3 のS/MIME機能で署名検証時に証明書の真正性が確認されない

としか書かれていないので、 どのバージョン以前にその脆弱性があるのか不明だ。

ベンダーの発表にも書かれていない。上のと同じことが書かれているだけだ*1

ジャストシステムの発表文は事実と異なる

JVN#B4BE09A4に 対するベンダーの発表文には誤りがあるので、届出者として知っている事実を 書き留めておく。

今回のベンダー発表文には次のように書かれている。

現象2:

(略)

Shuriken Pro3(*) では、署名メール開封時には、メールの内容が改ざんされ ていないことだけを確認し、署名に使われた証明書が信頼できるかどうかは、 [表示 - 暗号・署名情報の表示] によって、証明書に関する情報を表示して、利用者ご自身にご判断頂く仕様となっておりました

Shuriken Pro3の脆弱性として、S/MIME機能で署名検証時に証明書に関する確認が表示されない現象について

つまり、「証明書の信頼確認はメール開封時にはやらない仕様だった」と いうことが書かれているように読めるが、それは事実と異なる。 11月27日の日記「Shuriken Pro3 のS/MIME機能に何があったか」の図3に書いていたように、 古いバージョンでも、偽の認証局から発行した偽の証明書で署名したメールを 開封しようとすると、 きちんと「デジタル署名に使用された証明書が有効でありません。」 と警告が出る仕様になっていた。

11月27日の日記の図3の再掲

では、JVN#B4BE09A4 の件は、どういう脆弱性として届けていたかというと、次のものだった。

Shuriken Pro3 5.0.1.6 では、証明書のサブジェクト識別名の「EmailAddress」 欄を空にした証明書で署名したメールでは、 その証明書が偽認証局発行のものであっても、警告が出ないというバグがあった。

事実確認用の証拠としてその実例を以下に示す。

Date: Wed, 10 Nov 2004 12:10:40 +0900
From: foo@example.com
To: takagi@mail1.accsnet.ne.jp
Subject: S/MIME
 =?ISO-2022-JP?B?GyRCRkg8KxsoQkNBGyRCSC85VBsoQiAbJEIlYRsoQg==?=
 =?ISO-2022-JP?B?GyRCITwlayUiJUklbCU5JEokNz5aTEA9cRsoQiA=?=
 =?ISO-2022-JP?B?GyRCJE4lRiU5JUgbKEI=?=
X-SMIME-Plugin: Becky! S/MIME Plug-in v1.0.0rc2 build at Aug 13 2002 21:52:41
Message-Id: <20041110121031.B81D.FOO@example.com>
MIME-Version: 1.0
X-Mailer: Becky! ver. 2.11.02 [ja]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="===[S/MIME_RFC2311]===419186A7.31E220==="
Content-Transfer-Encoding: 7bit

--===[S/MIME_RFC2311]===419186A7.31E220===
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit

S/MIME署名のテスト

--===[S/MIME_RFC2311]===419186A7.31E220===
Content-Type: application/x-pkcs7-signature;
 name="smime.p7s"
Content-Disposition: attachment;
 filename="smime.p7s"
Content-Transfer-Encoding: base64

MIIE1QYJKoZIhvcNAQcCoIIExjCCBMICAQExCzAJBgUrDgMCGgUAMAsGCSqG
SIb3DQEHAaCCA5IwggOOMIICdqADAgECAgEDMA0GCSqGSIb3DQEBBAUAMGAx
CzAJBgNVBAYTAkpQMRAwDgYDVQQIEwdJYmFyYWtpMRAwDgYDVQQHEwdUc3Vr
dWJhMRQwEgYDVQQKEwtOYW5kZW1vIEFyaTEXMBUGA1UEAxMOTmFuZGVtbyBB
cmkgQ0EwHhcNMDQxMTEwMDMwMzU4WhcNMDUxMTEwMDMwMzU4WjBPMQswCQYD
VQQGEwJKUDEQMA4GA1UECBMHSWJhcmFraTEUMBIGA1UEChMLTmFuZGVtbyBB
cmkxGDAWBgNVBAMUD2Zvb0BleGFtcGxlLmNvbTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAoaVR4FS2YAIDNfMQ/J1U4WITcjrojSH67buWoSTA7bcK
xz1k0NxoEHdtGMlNIsk1mC+hGGEOThfU28UEpL4abpH5L26at0LE01S3z8TD
Gc8kjWzY9YA5VGp2VWuqDAlXyvbMDvNWkEERYLsWa1Rtak7Yk48eRp+CSix4
depkacMCAwEAAaOB5zCB5DAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1P
cGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQU/kFAV7lM
5frHBHfy15bFSPIVDCEwgYkGA1UdIwSBgTB/gBQxFSn6qdO2VZp/NfBCNnCb
p4nVvKFkpGIwYDELMAkGA1UEBhMCSlAxEDAOBgNVBAgTB0liYXJha2kxEDAO
BgNVBAcTB1RzdWt1YmExFDASBgNVBAoTC05hbmRlbW8gQXJpMRcwFQYDVQQD
Ew5OYW5kZW1vIEFyaSBDQYIBADANBgkqhkiG9w0BAQQFAAOCAQEANd6s8HeB
vZwTV0TRY8rrImEKtJCXCImf4hKFVedDQ0Keil4z6EFtu3fky83HqPc6NAuO
eYUpyCf4ciJb9sA0SLrntT46o/zyhfPx41JX8rjDkKwos5G/cObCpLdv7Msr
fwZc9Pmf/ZxqMtYxS4dCxu/trC7XgpHKp3ETOYn160cdnV/Gws1dMetOAXSu
oKW8HS4qkUKE4bddhhBSazjlCYOIKduKGIb+gzN0nfrk+p2uEaPqtbS56nhC
/Ag4AIjLzAC99NjzxmuRaE6+CUTSeTf3N12mtqv+aFtY5otOPBzpApfIUsWv
ul02Yt0Nd6D49dMadMlGOcPDQj/kt4wV6zGCAQswggEHAgEBMGUwYDELMAkG
A1UEBhMCSlAxEDAOBgNVBAgTB0liYXJha2kxEDAOBgNVBAcTB1RzdWt1YmEx
FDASBgNVBAoTC05hbmRlbW8gQXJpMRcwFQYDVQQDEw5OYW5kZW1vIEFyaSBD
QQIBAzAJBgUrDgMCGgUAMA0GCSqGSIb3DQEBAQUABIGAhWx8yvkvWJSn0hVb
c7FNIUjiiZuFLx+QgOfpCn5Fld0EtU0kek5FEvGFmuEjvdPFrL2qdZPhL4o7
+aLkmTd2+x7N1x7Lu7uG11USWTMpmn6H5HfFtxFpKM0Y1CdIbtx4qVSNnOBp
VJCd/qoJTT4fRdJPDDa9HKrQZn2rRPZyPzg=
--===[S/MIME_RFC2311]===419186A7.31E220===--

この問題は、前回のJVN#B410A83Fよりも いささか深刻だった。なぜなら、前回の件では、11月27日の日記 に書いたように、

図5の説明には若干の補足が必要である。

受信したメールの署名者の証明書を、証明書ストア*3に信頼済みのものとして登録していない場合(たとえば、初めての相手からのメールである場合)には、次の図のように、証明書ストアに登録するかと尋ねる確認ウィンドウが現れる。

という挙動を示すものだったが、今回の件では、この確認ウィンドウが現れる ことなく、本文が表示されてしまうからだ。

届出では、上のサンプルメールを添付して、以下のように説明した。

3) 脆弱性の種類

S/MIME署名されたメールの署名検証で不正な証明書が正当と誤判断される

Shuriken Pro3/R.2は、電子署名されたメールを表示するとき、「このメールは 暗号化、または、署名されています。」という表示とともに「復号・署名確認」 ボタンを出し、このボタンが押されると、署名検証をした後に本文を表示するよ うになっている。

本文が改ざんされたメールにおいては、この「復号・署名確認」ボタンを押した 時点で、「デジタル署名と署名された文書が一致しません。改竄されている恐れ があります。」という警告メッセージが出るようになっており、また、不正な証 明書で電子署名されたメールにおいては、「デジタル署名に使用された証明書が 有効ではありません。」との警告が出るようになっている。

これらのことから、このボタンを押して警告が出なければ、そのメールは真正の ものである(改ざんもなりすましもされていない)と利用者は理解する。

しかし、ある特殊な細工を施した不正な証明書を用いて電子署名したメールにお いて、「復号・署名確認」ボタンを押すと、何ら警告を出すことなく本文が表示 されてしまう。

4) 再現手順

(略)

2. テスト用自己署名認証局証明書等を用いて、以下の特徴を持つ特殊な証明書 を生成し、Windowsの証明書ストアにインストールする。

・サブジェクト識別名(DN)の「E」フィールド(EmailAddress)を空とする。

その実例を添付ファイル「smime2.crt」に示す。

3. その証明書を使ってS/MIME署名したメールを送信する。

(略)

6) 脆弱性により発生しうる脅威

特殊な細工を施した偽の証明書で電子署名されたメールを受け取ったとき、「復 号・署名確認」ボタンを押しただけでは真正のものと区別されないため、S/MIME が本来提供するはずの、なりすまし防止や、改ざん防止の機能が有効に働かない。

これを受信者がShuriken Pro3/R.2で表示した場合、ボタンを押しただけでは証 明書パスが検証されないため、詐称メールであることが検出されない。 また、攻撃者は、通信路上で本文の改ざんと同時に証明書もすり替えることができ、その場合にも改ざんの事実は検出されない

ちなみに、実は、このバグそのものは現在の最新版(バージョン 5.5.6.0) でも「修正」されてはいないようだ。

というのは、前回のJVN#B410A83Fが 5.5.6.0 で修正されたことによって、このメールを開こうとすると、

署名者のメールアドレスと差出人のメールアドレスが一致しません。

の警告が出るようになった(署名者のメールアドレスが空なので)ため、 結果的に、これによって偽メールだと気づくことはできるように なっている*2

しかし、偽認証局発行のEmailAddressが空でない証明書で署名され、 かつ、Fromが署名者アドレスと異なるメールで実験すると、5.5.6.0 は、

デジタル署名に使用された証明書が有効ではありません。

の方の警告を出す(アドレスが一致しませんの警告は出ない)ことから、 このバグ自体は残っていると推察される。

偽メールに対して何かしらの警告は出るようになったのだから、5.5.6.0 で 脆弱とはいえなくなっているといえるにしても、 いまひとつきちんとした警告が出ないままの状態といえるのではなかろうか。

こういうのに比べて、Outlook Expressの警告表示はよくできている。 Microsoftはさすがだ。

*1 「アップデートモジュールのダウンロードはこちら」と書かれたリンク先にある、 アップデートモジュールのページ(「公開日2003.04.18」のページ)には、 「バージョンが記載バージョン以降であれば、導入いただく必要はありません。 5.5.6.0 (2004.11.18更新)」といちおう書かれてはいるが、 ここは新しいアップデートモジュールが出るたびに書き換えられるところ なので、今回の脆弱性がいつのバージョン未満までに影響があるのか、 しばらくすると不明になってしまう。

*2 私が今回の脆弱性を届け出たのは、5.5.6.0のパッチリリースを知るより前だった。

本日のTrackBacks(全100件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20041221]

Do most take zoloft in evening or morning. Zoloft 12.5mg and a thirteen year old. Lexapro zoloft wellbutrin. Zoloft.

Adderall.

Compare auto insurance. Aaa auto insurance. Car auto insurance. Gieco auto insurance quotes. Auto accident insurance claim. Auto insurance.

Gmac mortgage. San diego mortgage. Option one mortgage. Mortgage calculator. Home mortgage rates. San diego mortgage loans.

検索

<前の日記(2004年12月19日) 次の日記(2004年12月25日)> 最新 編集

最近のタイトル

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
<前の日記(2004年12月19日) 次の日記(2004年12月25日)> 最新 編集