高木浩光＠自宅の日記

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

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はさすがだ。