こんにちは。KUSANAGIの開発チームで取締役をしている相原です。
「KUSANAGI」はWordPressをはじめとするCMSを高速に動作させる世界最速クラスの仮想マシンです。わたしたちは「KUSANAGI」を開発して皆様にご利用いただくほか、お客様のWebサイトを「KUSANAGI」で運用しています。
この連載では、「KUSANAGI」の開発やお客様とのお話の中で感じた課題や実際の運用の中で得た知見などをお伝えしています。
昨年（2021年）末はApache Log4jの脆弱性が大きな話題となりました。今回は「脆弱性について、「KUSANAGI」開発チームの開発リーダーがお話します。
はじめに
はじめまして、プライム・ストラテジー「KUSANAGI」の開発チームの石川です。今回は「KUSANAGI」の視点から脆弱性とその対応についてお話したいと思います。
2021年12月に明らかになったApache Log4jの脆弱性（CVE-2021-44228）については耳にした人は多いと思います。中には対応に追われた方もいることでしょう。
Apache Log4jはJavaで書かれたアプリケーションでログを出力する際に用いられる一般的なライブラリです。そして、Javaで書かれたアプリケーションが世の中に多くあることから、本脆弱性は波紋を呼ぶことになりました。
今回は脆弱性がテーマではありますが、Apache Log4jの話ではないのでこの話はこのくらいにしておきます。
実は昨年末に脆弱性が明らかになったのはApache Log4jだけではありません。ウェブテクノロジーに関わるものだけでも
・NSS（Network Security Service）（CVE-2021-43527）
・Apache HTTP Server（CVE-2021-44790）
など深刻度が重要（High）、緊急（Critical）で公開されています。深刻度は警告（Medium）ですがNginxも公開されています。
このように重要度の差はありますが、脆弱性への対応は必須であるといえます。
脆弱性とは
そもそも脆弱性とは何でしょうか。
ソフトウェアは人間が作り出したものである以上、完璧ではありません。不具合や障害はつきものです。それらの不具合によって動作しなくなるだけならまだよいのですが、そこから更に別のシステムを攻撃するために用いられたり、中の重要な情報を抜き出すために利用されたりすることがあります。
こういったセキュリティ上のリスクとなる不具合や障害を脆弱性といいます。
「はじめに」で上げた深刻度は、この脆弱性の「悪用しやすさ」といってもいいでしょう。深刻度が高ければ高いほど他の攻撃者に悪用されて、重要な情報を抜き取られるリスクが上がると考えてもらっていいです。
なお、脆弱性にはCVE-XXXX-XXXXといった番号がついているのにお気付きでしょうか。これは共通脆弱性識別子CVE（Common Vulnerabilities and Exposures）と呼ばれるもので、アメリカ政府の支援を受けた非営利団体MITRE社が採番しています。
脆弱性自体はそれぞれの製品開発元や各組織で採番していますが、それを一意の識別番号として利用できるようにしたものです。
では、そもそもそういった脆弱性はどうして悪用できてしまうのでしょうか。1つ例を挙げます。コンピューターは情報を基本的にはメモリに格納して処理します。メモリに格納する場所は決まっているのですが、不具合や障害によって予期しない場所に書き込んでしまえることがあります。これを「バッファーオーバーフロー」と呼びます。
これ自体は即座に悪用できるものにはならないので、深刻度が低い場合もあります。しかし、重要な情報（たとえばパスワード）を任意の場所（たとえばログや画面）に出力できるような不具合だった場合は、深刻度の高い脆弱性となります。
深刻度が高い脆弱性は、その方法が既に公開されているか想定されやすいものである場合が多いです。それゆえ、脆弱性が明らかとなったら即座の対応が必要なのです。
また、攻撃者はつねに悪用できる脆弱性がないか研究をしています。今は悪用の方法が公開されていないだけで、明日使われない保証はありません。よって、深刻度が低いからといって脆弱性の対応をおろそかにしてはいけません。
KUSANAGIの対応
さて、脆弱性の対応は必要なものではありますが、運用をしている環境で対応するのは難しい場合もあります。まず判断するのは、その機能が使われているかどうかです。
「はじめに」で上げた3つの脆弱性についてですが、幸いにしてApache Log4jの対応はKUSANAGIにはありませんでした。
KUSANAGIはWordPress等のPHPを高速に動作させるための仮想マシンです。Javaを用いたプログラムやライブラリは標準ではインストールしていないため、JavaのライブラリであるApache Log4jがそもそも組み込まれていなかったのです。ただ、あとから各利用者が必要なアプリケーションをインストールしたことにより、Apache Log4jがインストールされる場合はあります。
NSS（Network Security Service） はSSLによる暗号化通信の際にその証明書に関する処理を行なうライブラリで、SSLに対応したプログラムで広く使われています。コマンドラインでHTTPS経由の接続を行なう際に使うcURLやWgetもNSSを利用しています。
WordPressをはじめとしてPHPのコードでHTTPSの通信を行なう場合もcURLを利用することが多く、結果的にNSSを利用していることになります。
NSSの脆弱性はApache Log4jと異なり、即座に悪用する方法が明らかにはされていません。ですが、SSL証明書に関わる処理に使われているライブラリであることから、証明書の改ざんや偽装、ひいては暗号化通信の解読……なんてことにつながらないとは言えません。今やHTTPSが標準の時代、NSSの更新は必須でしょう。NSSはKUSANAGIで提供しているライブラリではなく、ベースとなっているCentOSが提供するライブラリになります。
なお、サポートが終了したCentOSではこれらの更新が行なわれません。そのため、KUSANAGIはサポートが継続しているCentOSのみで提供するようにしています。2021年12月31日でサポートが終了したCentOS 8でのKUSANAGIの提供は終了しました。
Apache HTTPD ServerやNginxはKUSANAGIでも採用しているWebサーバーのプログラムになります。こちらはベースとなるCentOSでも提供されていますが、KUSANAGIは最新のバージョンをKUSANAGIのライブラリ・プログラムとして提供しています。
当社では各ミドルウェアのリリース情報を監視して、脆弱性に対応したバージョンがリリースされたら即座にKUSANAGI用にリリースする仕組みを構築しています。おおむね数日以内には公開するようにしています。
アップデートを適用する CentOSが提供しているプログラム・ライブラリであれば、更新はyum updateコマンド（CentOS Stream 8/9では dnf update コマンド）で行ないます。同様にKUSANAGIが提供しているプログラム・ライブラリも更新はyum updateコマンド（CentOS Stream 8/9では dnf update コマンド）で行ないます。
OSSの脆弱性への対応は最後はエンドユーザーの判断
しかし、各利用者がPHPのcomposerやNodeJSのnpm、Pythonのpipでインストールしたプログラム・ライブラリの場合は上記の方法では更新できません。KUSANAGIの上位エディションであるPremium EditionではNodeJSやPythonのモジュールを利用していますが、KUSANAGIのプログラム・ライブラリ同様にyum update/dnf updateで更新できるような形で提供しています。
つねに最新の脆弱性情報を入手して、利用しているプログラム・ライブラリにそれらがないかは、各利用者が自分で判断しなくてはなりません。
それぞれのアップデートコマンドで更新がないからといっても安心はできません。サポートが終了していたり、ただ誰も脆弱性の対応をしていないから、という場合があるからです。
オープンソースは非常に有用なものではありますが、それを利用して運用する責任もまた利用者にあるということをつねに意識していきましょう。対応を怠ったことによって、自社サービスが悪意をもって利用されてしまったり、重要な情報が抜き取られてしまってからでは遅いのです。
