GoogleのTLSライブラリ「BoringSSL」の証明書の検証に、名前制約(Name Constraints)を回避できる問題が報告されました。本来は特定のドメインに限られるはずの証明書を、別のホストのものとして正当だと誤認させうる、という種類の問題です。ただし、「BoringSSLを使っていれば必ず危ない」という話ではありません。条件を正しくおさえるのが大事です。この記事は、JVNとCERT/CCの情報をもとにまとめます。
何が報告されたのか
BoringSSLは、GoogleがOpenSSLから派生させて、自社の用途向けに開発しているTLS・暗号のライブラリです。多くのGoogle製品や、そこから派生したライブラリの土台になっています。
今回報告されたのは、X.509証明書の検証で使う「名前制約」のチェックを、回避できる場合がある、という問題です。名前制約は、「この中間CA(認証局)は、この範囲のドメインの証明書しか発行してはいけない」といった制限をかける仕組みです。これが回避されると、本来は許されないドメインの証明書が、正当と検証されてしまい、なりすましや中間者攻撃の土台になり得ます。
CERT/CCには5件の指摘があり、それぞれ状態が異なります(修正済みのもの、調整中のもの、却下されたものなど)。
「使っている＝危ない」ではない
ここが、いちばん大事な点です。
実際に影響するのは、次のような条件がそろう場合です。
- 名前制約が有効な経路で、証明書を検証している
- 攻撃者が選んだ名前(SAN)に、信頼された署名が付く
- 検証で受理された名前が、認可(アクセスの許可)の判断に使われる
また、CVE番号やCVSS(深刻度のスコア)、影響を受けるバージョンの番号は、一次情報には示されていません。修正はコミット単位で行われています。実際の悪用の報告も、確認されていません。
業界を横断した、名前制約の問題
今回は、BoringSSL単独の話にとどまりません。同じ研究者が、ほかのTLSライブラリの、同じ種類の問題も、協調して公表しています。pyca/cryptography、rustls、GnuTLS、wolfSSL、Goのcrypto/x509などで、そちらにはCVE番号が付いています。証明書の名前制約の実装は、各ライブラリで共通の落とし穴があった、という業界横断の話として見るのが正確です。
影響する会社・しない会社
- 影響する(可能性がある): BoringSSLや、同種の問題が報告されたTLSライブラリを組み込んだ製品を使い、名前制約を使った証明書の検証をしている場合。とくに、検証した名前を認可の判断に使っている場合。
- 影響する: 自社で、これらのライブラリを使ってアプリやサーバーを開発している会社。上流の修正の取り込みが要ります。
- 影響しにくい: 名前制約を使った検証の経路を通っていない場合。CERT/CCも、ライブラリを含むだけでは対象とは言えないとしています。
情シスが今日やること
- 製品の更新で対応する。利用者側の対策は、原則として、該当のライブラリを組み込む製品(ブラウザ、アプリ、サーバー)の更新を待って当てることです。
- 使っているライブラリを把握する。自社で開発・運用するものに、BoringSSLやGnuTLS、Goのcrypto/x509などが使われていないかを確かめます。使っているなら、上流の修正の取り込みを検討します。
- 過度に煽らない。「BoringSSLに脆弱性」という見出しだけで、全製品が危ないと早合点しないことです。条件がそろう場合に限られる、という点を、社内に正確に伝えます。
- 証明書を発行する側は形式を整える。SAN(サブジェクト代替名)を、整った形式で発行することが推奨されています。
