皆様こんにちは。ウィスキーとサウナと四谷たけださんの牡蠣バター焼きをこよなく愛するVulsの神戸です。
突然ですが君たちの脆弱性調査は間違っている(かも)
普段こんな手順で脆弱性調査をしていませんか。
- JVNやNVD, JPCERT/CCなどで脆弱性情報を収集している
- 危険な脆弱性が公開されたら社内に周知して運用者に影響調査を指示する
- 運用者はrpmやdpkgコマンドで該当ソフトウェアのバージョンを調べる
- NVD記載のバージョンと、コマンドで取得したバージョンを比較して判断する
もしこの方法でやっているという方はバージョン比較の判断方法を間違えており、過去に調査済みの脆弱性がシステムに残存している可能性が高いので、ぜひ本記事をお読みください。
本記事では正しい調査方法と、Vuls内部で実現している検知処理について紹介します。
君はバックポートを知っているか
バグのないソフトウェアは存在しません。Ubuntu, Debian, RHEL, Amazon LinuxといったメジャーなLinuxディストリビューションに含まれるソフトウェアにも悪用可能なバグ（脆弱性）は沢山存在します。OSSコミュニティやLinuxベンダーはバグや脆弱性を修正し日々修正版をリリースしています。ITシステムの運用担当はaptやyum, dnfなどのパッケージマネージャを用いて適切なタイミングで脆弱性やバグを解消しながらシステムを運用していく必要があります。
運用担当にとっては安定運用が重要です。「システムをアップデートしたら再開できませんでした」となると重要システムの場合、企業活動が停止し様々な方面から叱咤激励をうけることになります。このため運用者としては安定運用を重視したくなりついアップデートせずに放置したくなります。ただ、それだとバグを含んだ状態で運用することになります。そのバグがいつ発動してより大きな障害になるかは誰にもわかりません。また脆弱性を含んだ状態で運用すると悪意のある人物やプログラムに悪用される可能性があります。世の中には様々なOSSやセキュリティ製品がありますがそれらを導入しても、場合によってはマスクや絆創膏くらいの効果なのかもしれません。これらのバグや脆弱性を修復するためにはソフトウェアアップデートが根本的な解決策です。
ええ、そんなことは頭では分かっています。システム運用者にとってはとにかく安定運用が重要です。ジレンマです。
システム運用者のこのジレンマを解消するためにバックポートという仕組みが存在します。
「機能はそのままで重大なバグや脆弱性は修正したい」「互換性を保った状態でアップデートしたい」というニーズを実現するためにLinuxベンダーやコミュニティからバックポートとよばれる仕組みで更新が提供されます。
Wikipediaによるバックポートの定義を引用します。
1 | バックポート (英: backporting)とは、ソフトウェアシステムやソフトウェアコンポーネントの新しいバージョンからパーツを取得し、それらを同じソフトウェアの古いバージョンに移植するアクションのこと。これは、ソフトウェア開発プロセスのメンテナンス段階の一部であり、一般的には、ソフトウェアの古いバージョンのセキュリティ問題を修正するため、および古いバージョンに新しい機能を提供するために使用される。 |
一般的にLinuxディストリビューションの新しいバージョンがリリースされたタイミングで、それに含まれるソフトウェアのバージョンは固定されます。そしてメンテナンス期間中は基本的に機能面の大きなバージョンアップは実施されません。
それでは、バグや脆弱性はどのように修正され、システムに配布されていくのでしょうか。
バグや脆弱性はまずUpstreamと呼ばれる各ソフトウェアの本家のリポジトリで修正されます。その後Linuxベンダーやコミュニティが、それぞれの製品に含めた過去のバージョンに対して、互換性を維持するよう上手に該当の修正をパッチ適用します。そしてリポジトリ経由で修正モジュールを配布することで脆弱性を修正します。
バックポートの詳細は下記の資料がわかりやすいので参照してください。
このように、互換性を維持しながら重要なバグや脆弱性のみを更新したいというニーズの実現のためにLinuxではバックポートの仕組みにより更新が提供さます。
思い出深い懐かしのHeartBleed
次に、ある脆弱性がUpstreamと各種Linuxのどのバージョンで解消されたのかを具体的に見ていきましょう。
だいぶ古いですが2014年に世間を騒がせたCVE-2014-0160: HeartBleedのUpstreamと各Linuxディストリビューションごとの修正バージョンを表にまとめました。
| 情報ソース/Linuxの種類 | HeartBleedの修正バージョン・リビジョン |
|---|---|
| Upstream | 1.0.1g |
| NVD | 1.0.1g |
| Red Hat Enterprise Linux Server 6 | 1.0.1e-16.el6_5.7 |
| Debian stretch | 1.1.0l-1~deb9u1 |
| Debian buster | 1.1.1d-0+deb10u7 |
| Ubuntu Precise | 1.0.1-4ubuntu5.12 |
この表を見ると以下のことがわかります。
- NVDはUpstreamのバージョン番号が掲載されている
- RHEL, Debian, UbuntuはUpstreamとは違うバージョンで修正されている
このようにUpstreamの本家のバージョン体系とLinuxに含まれるソフトウェアのバージョン体系は異なります。記事冒頭で書いた調査方法だとUpstreamのバージョンとバックポートのバージョンを比較してしまっており判断を誤ることになります。正確に判断するためには「対象のLinuxの種類とバージョン」のベンダーのサポートサイトを参照します。そしてそこに記載された「バックポートを考慮したバージョン」と、「rpmやdpkgで取得したバージョン」を比較して判断しなければいけません。
ただし上記の表のとおり、同じ脆弱性でもOSの種類とOSのバージョンごとにFixされたバージョンが異なるため、手動での影響調査はとても面倒で間違いやすい作業になることでしょう。
FutureVuls / Vulsで正確な検知を
このように影響調査は人手でやろうとすると大変な作業のため、ツールを使って検知しましょう。 FutureVuls / Vulsはバックポートを考慮した適切な情報ソースを用いているので検知が正確です。2016年4月1日にOSSとして公開して以来、世界中の人に使われており、1200以上のcommitを重ね検知ロジックに磨きをかけています。
手動で脆弱性管理をされている方はぜひFutureVuls / Vulsを使って正確に脆弱性管理していただければ開発者として本望です。