第28回　2016年11月～Microsoft製品の脆弱性情報提供が変更に＆Apache Tomcatの脆弱性

Microsoft、セキュリティ情報の提供を変更～今後はSecurity Updates Guideに

Microsoftからこの11月に、今後新たな脆弱性情報の仕組みを提供する旨公表されました。

Security Updates Guideとは何か

Security Updates Guide（日本語では「セキュリティ更新プログラムガイド」と呼称）は、Microsoft製品の脆弱性情報を提供する新たな仕組みです。

セキュリティ更新プログラムガイド: https://portal.msrc.microsoft.com/ja-jp/security-guidance

2016年11月の段階でPreviewが公開されています。

これまでセキュリティ情報に掲載されていた脆弱性情報は、MSxx-xxxという形で管理番号が付与されていました。Microsoftのセキュリティ情報は、人間が読むのはやりやすいものの、セキュリティ情報の取得や分類などの処理を、自動化するためのAPIなどは提供されていませんでした。

Security Updates Guideを経由した情報提供が開始されることで、以下のものが提供されるようになります。

CVE番号、KB番号、日付、製品名でのフィルタリング機能
RESTful API

今後、セキュリティアドバイザリはなくなり、Security Updates Guide一本に

Microsoft製品の脆弱性というと、MS16-xxxみたいな感じで示すことができるのですが（下図⁠）⁠、それも2017年1月までになりそうです。2017年1月の定例アップデートまでは、従来のセキュリティアドバイザリとSecurity Updates Guideの両方でセキュリティ更新情報を確認できますが、その後はSecurity Updates Guideのみになります。

Security Updates Guideで提供開始＆従来のセキュリティアドバイザリ提供を2017年1月で終了: https://blogs.technet.microsoft.com/jpsecurity/2016/11/09/furthering-our-commitment-to-security-updates/

脆弱性情報を確認している人は、今からSecurity Updates Guideの使い方に慣れておくのがよいでしょう。

2016年11月に出たApache Tomcatの脆弱性～他ベンダにより修正された脆弱性の確認漏れ？

2016年11月22日に、Apache Tomcat の脆弱性3件をFixした旨が、Apache Tomcat Projectから公開されました。

今回の脆弱性で見るべきところ

今回の脆弱性はそれぞれ「リモートコード実行」「⁠情報漏えい」「⁠サービス妨害」なので、これだけ見たら「修正しなきゃ」でおわるのですが、私が見たところ、1件の脆弱性修正の内容に少し見るべき点がありました。それは、CVE-2016-8735の修正に関する以下の説明によります。

Apache Tomcat 9 vulnerabilities: https://tomcat.apache.org/security-9.html

The JmxRemoteLifecycleListener was not updated to take account of Oracle's fix for CVE-2016-3427.

これは、「⁠CVE-2016-3427で修正された内容を考慮してなかったために発生した脆弱性」ということを意味します。他のソフトウェアで発見された脆弱性が、直接的に他のソフトウェアにも影響する実例とも言えます。

CVE-2016-3427の概要は、以下のページの中から確認できます。

Oracle Critical Patch Update Advisory - April 2016: http://www.oracle.com/technetwork/security-advisory/cpuapr2016v3-2985753.html

今回の脆弱性が残した教訓

最近のソフトウェアは、多くの情報がインターネット上から入手可能ですし、最悪それらの情報をつなぎ合わせて（コピペで）なんとか動くコードを作れる、という時代です。しかし、何をどこから持ってきて、自分が作ったコードに何をさせようとしているかがわからないと、コピー元のコードに脆弱性があってもそれを気づくことができません。

コードの引用／複製等を意図せずやった場合には、よく言われるライセンス問題以外にも、今回のように「引用元／関連するソフトウェアに残存している脆弱性が、自分の書いたソフトウェアにも埋め込まれる」という危険性があります。そして、この種の課題にも対応できるように、ソフトウェアの開発や維持のフェーズでやっておくべきことの中に、「⁠構成管理」や「変更管理」があるのですが、このような管理を行えていないと、今回Apache Tomcatで見つかったのと同じような、他のソフトウェアに起因する脆弱性に気付けない危険性もあります。

結論：何気なくコピペして使っているコードや自システムの構成には気をつけよう

何かのコードを書いていて、何も気にせずコピペしていると、たまたまどこかから持ってきた／参考にしたコードが脆弱だった場合に、そのコードの脆弱性が「自分が作ったものにどう影響しているのか」すらも調査できなくなることがありえます。

日常的にソフトウェアを書いている人にとっては、あたりまえとも言えることなのですが、自分は何をさせるためにコードを書いているのか？は、最低限把握しておき、そのために必要な引用を行ったり、参考にしたコードがある場合には、何をどこから持ってきたのか／何を参考にしたのかくらいは管理しておくようにしましょう。

複数のソフトウェアを協調動作させているシステム等でも、何を使っているかの把握を行う等はやっておきましょう。脆弱なソフトウェアを使っているとわかったら、入れ替えを行うための影響調査を行える準備をするのが吉と言えます。