高木浩光＠自宅の日記

■ 開発者のプライドか、それとも「脆弱性」のネガティブイメージの影響か

ソフトウェアにセキュリティ脆弱性が見つかると、そのソフトウェアのことを蔑 んで見る人がいるかもしれない。たとえば、「マイクロソフトは糞だ」みたいな ことを言いたい人からすれば、同社の製品に脆弱性が見つかると軽蔑の目でもっ てその事態を見ることになる。

さて、JVN#E59B594Bが 発表された。 これは、 鶴亀メールのS/MIME機能*1が、署名メールの証明書パス（証明 書チェイン）が検証されないものだったという欠陥である。

これについてのベンダーからの告知は、「改版履歴」のペー ジで次のように説明されている。

2004/10/16 V3.69 -> V3.70 バグ修正／仕様変更

• [重要]メールが１通も無いフォルダ上で「下の未読メール」などを実行すると死んでしまうことがあるバグ修正。（V3.69でのレベルダウン）
• [重要]S/MIME電子署名されたメールの検証で、電子署名自体は検証しつつも、証明書の検証がなされてなかったバグ修正。証明書が失効されてるかどうかもチェックできるボタンも追加した。
  （略）

「電子署名自体は検証しつつも」といっても、S/MIMEにおいては、証明書の検証がなされなければ、電子署名としての役割を全く果たさない。

なぜなら、S/MIMEにおいては、メールに署名を施すと、その署名を検証するため の公開鍵が証明書の形式で添付されて、本文や署名と共に送信される。受信側は、 送られてきた本文、署名、証明書から、本文が改竄されていないかを確認するこ とになるが、当然ながら、受信した証明書までもが同時に改竄されている可能性 があるわけだから、証明書が本物かどうかを何らかの方法で確認しなくてはなら ない。それを処理するのが、証明書パスの検証*2である。

しかしながら作者氏は、サポー トフォーラムにおいて次のように述べていた。

秀まるお2 さん　04/10/14 16:40

実は、とあるセキュリティ関係の人から連絡を受けたんですが、鶴亀メールの S/MIME関係で脆弱性があります。脆弱性と言われたのでこりゃ大変だと 思ったですが、実は以前から僕自身が手抜きしてた所でして…

S/MIME電子署名されたメールを検証する時に、実は鶴亀メールはその電子署名の 有効期限のチェックをしていません。なので、有効期限が切れていても、特に有 効期限が切れているとかってメッセージが出ないです。

あと、電子署名された証明書のパスというか、その電子署名の発行元、さらには それの発行元（最終的にはベリサインに行き着く？）の検証もしていません。な ので、仮にそういう、個人で作ったような証明書であっても、特に警告は出ない です。

その辺ご注意お願いします。

秀 シリーズサポートフォーラム, 鶴亀メール 情報交換, S/MIMEでの脆弱性の報告

秀まるお2 さん　04/10/14 22:40

とりあえず、

1. 証明書の期限のチェック。
2. 証明書パス（certificate chain）についての正当性の検証。具体的には、CertVerifyCertificateChain関数によるチェック。
3. 証明書のメールアドレスとメールのFrom:メールアドレスの一致チェック。

を入れることにします。（略）

ただ、元々こういうチェックをしてないからといって、それを「脆弱 性」 呼ばわりされるのはどうかという気もします。例えば、証明書の有効 期限を過ぎ照る場合に「有効期限を過ぎてない」と出したらまずいでしょうが、 有効期限について特に何も言ってない分には問題ないというか、そういう仕様 （チェックしてないという仕様）でもいい気もします。

秀 シリーズサポートフォーラム, 鶴亀メール 情報交換, S/MIMEでの脆弱性の報告

修正されたようなので問題点は理解されたようにも見受けられるが、「チェック しない仕様でもいい気もする」というのはどういうことだろうか。

有効期限について期限切れでも警告を出すことがない（期限を表示させて目で確 認する方法が別途用意されている）というのは、あり得るかもしれないとしても、 証明書パスの検証をしない仕様というのは、S/MIME対応を謳う限り、あり得ない ことだ。

作者氏はなぜこういう思考をしてしまうだろうか。「脆弱性と言われたのでこりゃ 大変だと思った」が、大変なことじゃなかったという認識だと思われる。「脆弱 性だ」と認めるのは受け入れがたいことなのだろうか。

ひとつの可能性は、「脆弱性」という言葉が、凶悪なワームに即座に感染するよ うなものだけを連想するという、狭い意味で理解されているのかもしれない。

しかし、S/MIME対応と聞いてそのメーラを使っている人が、信頼する相手から電 子署名されたメールが来たため、完全にその内容を信用して、次のアクションを 起こした（添付ファイルを開くとか、リンク先に情報を入力するとか）ときに、 それが偽だったことによって受け得る被害は、「こりゃ大変だ」という感想に相 応しいものとなり得るはずだ。

「脆弱性」とは、単純に、ソフトウェアの欠陥のうち、悪意ある者によって意図 して悪用される危険性（攻撃にさらされやすい）のあるものを指す。

そして、ソフトウェアの「欠陥」とは、仕様（明示的および暗黙的な）を満たさ ないものを指すのであり、S/MIME対応を謳う仕様においては、証明書パスを検証 しないのは、仕様を満たしておらず、単純にそれは欠陥である。

欠陥とか脆弱性という言葉は、本来は単に事実を指す言葉であるが、社会的な気 運のなかで、言葉にネガティブなイメージが付きまとうことはあるかもしれない。 しかし、だからといって、技術者が、そうした言葉で表現せざるを得ない事実の 指摘を受け入れがたいと感じるようでは、個人的軋轢や社会的困難が生ずるであ ろう。

もし、無償ソフトや評価版などにおいて、実装をサボった状態でリリースしたい のであれば、S/MIMEには完全には対応しておらず、何と何が未サポート（だから 何々には注意せよ）だとする説明の下で配布すればよい。

念のため、S/MIMEの仕様を確認しておく。

RFC 3850「Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling」には次の ように書かれている。

4.2. Certification Path Validation

In creating a user agent for secure messaging, certificate, CRL, and certification path validation SHOULD be highly automated while still acting in the best interests of the user. Certificate, CRL, and path validation MUST be performed as per [KEYM] when validating a correspondent's public key. This is necessary before using a public key to provide security services such as: verifying a signature; encrypting a content-encryption key (ex: RSA); or forming a pairwise symmetric key (ex: Diffie-Hellman) to be used to encrypt or decrypt a content-encryption key. （略）

また、Security Considerationsの節には次のように注意書きされている。

Some of the many places where signature and certificate checking might fail include:

• no Internet mail addresses in a certificate matches the sender of a message, if the certificate contains at least one mail address
• no certificate chain leads to a trusted CA
• no ability to check the CRL for a certificate
• an invalid CRL was received
• the CRL being checked is expired
• the certificate is expired
• the certificate has been revoked

There are certainly other instances where a certificate may be invalid, and it is the responsibility of the processing software to check them all thoroughly, and to decide what to do if the check fails.

追記

「電子署名自体は検証しつつも」といっても、S/MIMEにおいては、 証明書の検証がなされなければ、電子署名としての役割を全く 果たさない。

だが、それがしたいのなら公開鍵暗号なんて使わなくていい。チェックサムでも 使っておけばいい。

■ JVNにおける「想定される影響」の書き方

今回の事例で、「想定 される影響」の項目は、

想定される影響

自己署名証明書によって生成できる任意のメールアドレスを詐称する証明書で S/MIME署名されたメールを受信しても、受信者は詐称メールであることに気づか ない可能性があります。

と書かれているが、これは届出者（私）が次のように報告したところから影響さ れたものだろう。

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

自己署名証明書によって生成できる任意のメールアドレスを詐称する証明書で S/MIME署名されたメールを受信しても、受信者は詐称メールであることに気付か ない。S/MIMEとして誤った実装であり、なりすまし防止としての機能を果たして いない。

しかし、これらの説明は、技術者向けにはよいとしても、一般ユーザ向けにはど うだろうか。「自己署名証明書によって生成できる……」とかいう書き出しになっ ている時点で、既に読まれないのではなかろうか。

というわけで、次回からは、「脆弱性により発生しうる脅威」には一般ユーザ向 けの説明を冒頭に書くように心がけることにする。

今回の件ならば、次のように書くべきであった。

偽の証明書で電子署名されたメールを受け取っても、本物と区別されないため、 S/MIMEが本来提供するはずの、なりすまし防止や、改ざん防止の機能が有効に働 かない。

具体的には、自己署名証明書などで生成できる任意のメールアドレスを詐称する 証明書でS/MIME署名されたメールを受信しても、受信エージェントは、証明書パ スを検証しないため、詐称メールであることを検出しない。また、メール本文が 改ざんされて届けられた場合にも、証明書も同時にすり替えられていれば、その 事実は検出されない。