OSS利用ソフトウェアの脆弱性リスク

公開日：2022.09.13｜

更新日：2024.08.29｜

PDFダウンロード

アクティブディフェンス

OSSとは

OSSとは「オープンソースソフトウェア」の略ですが、これは言ってみればメインフレームからオープン系のサーバに移行した、いわゆる「オープンシステム化」から出てきた発想です。

オープンシステム化以前は、メインフレームあるいはミニコンピュータと呼ばれるプロプライエタリ（専有の）システムで企業等はコンピュータシステムを構築していました。

ユーザは主に要望を伝え、メーカがそれに則ったものをつくる、本来ユーザが行うべきことをメーカに依存していたとも言えます。

OSも独自であり、オープン系の走りであったUnixも各社が独自にBSDなどをプロプライエタリのハードウェアに合うように修正していた時代でした。

もちろんミドルウェアもなく、ただシステムを使うために必要なエディターや管理ソフトは各社のOSに合わせて提供され、同じユーザ（本当はそのメーカのエンジニア）が利用していました。

OSSとは

恐らく共通化の波がいち早く到来したのは通信ネットワークでした。

その昔は電話が唯一の通信手段だったために、電話機に付ける音声カプラー（音声をデジタル信号に変換する機械）や、その先に繋ぐモデムは名前が統一されていましたが、これらも機能的には方言のような独自性があったために、どれとどれは繋がる、あるいは繋がらないといったことが往々にして起こっていました。

しかし、通信をするためには同じ規格である必要があり、米国電気電子学会（IEEE）や国連の組織である国際電気通信連合（ITU）が規格化を行いました。

オープンシステム化の波は、恐らく30年以前の1990年代から流行りはじめ、ネットワークに限らず様々な規格が標準化され、それがソフトウェアの部品化にも波及していきました。

それまではコンピュータ同士をつなぐために、独自OSを用いて、X.25の規格を用いてかろうじて通信ネットワークをつないでいた、という状態でしたが、ソフトウェアの部品化によりソフトウェア自体も多くの場面で使われる機能（例えばログを取る、入力をチェックする）から、複雑な機能（例えばリレーショナルDBの部品）までもが部品として規格化され使われるようになりました。

もちろん、複雑な機能の部品はボランティアとして活動する多くの高度なエンジニアが参画していましたが、簡単な機能は少人数のエンジニアが支えていました。

しかし、そのソフトウェア部品を使う人達は、誰がどの程度の規模でOSSを支えているかなどは論点でなく、部品の有無自体に関心があったので、利用による開発期間やコスト削減を錦の御旗とする状況になり、現在のOSS利用が当たり前の状況を作りました。

OSSのセキュリティ対策を検討されている方へ

従来型AVでは防げないゼロデイ攻撃への対策について解説

OSSの脆弱性*1

ブログ「Linuxシステムへのサイバー攻撃」で、

「OSSでは多くのボランティアが、複数の目でOSのカーネルに、あるいはディストリビューションに脆弱性（セキュリティ的なバグ）の有無を見つけ、修正するので結果として、脆弱性が少なく、修正までの時間も短い」という特徴を紹介しました。しかし、SBOMの発展や浸透によりOSSも様々なアプリケーションに必要な機能に拡張し、種類が多岐にわたっています。これにより、特定の機能を複数の目で確認する機会が減り、セキュリティ上のバグ等が修正される頻度が下がり、攻撃に対して脆弱になっていることは事実です。」

とご紹介しました。

仮にLog4jの様に単にロギングをするという基本的な機能を提供するOSSであれば、このプロジェクトに参加しているボランティアが少数かもしれません。

そうすると例えば1名のエンジニアが抜けたあるいは、現業が忙しくなりプロジェクトへの参加時間が限られた場合などは、OSSの脆弱性の発見が遅れることが想定されます。

つまり、OSSを利用すること自体にリスクがあるにも関わらず、「OSSは多くのボランティアが複数の目で脆弱性の発見や修正をしている」と信じることにもリスクがあります。

Log4jにはLookupと呼ばれる機能があり、この機能に脆弱性が発見されました。

攻撃者が悪意を持って文字列を送信し、ログとして記録すると、指定された通信先あるいは内部パスからjava classファイルを読み込み実行するために、任意のコード実行ができてしまう脆弱性（CVE-2021-44228）の存在が確認されました。

したがって、修正されたLog4jでは、Lookup機能をデフォルトで無効にする、あるいは削除するという対策が採られています。

また、この脆弱性に関連してサービス運用妨害攻撃対策の脆弱性（CVE-2021-45046）、およびLog4jの設定によっては影響を受ける脆弱性（CVE-2021-45105）も修正されています*2。

因みに、このLog4jになぜLookup機能が必要であったかは不明だと言う人も居ました。もちろん、コードデバックの時には有効だと思いますが、その目的だとすると正式なリリース版に入れるべきファンクションではなかったと思います。

話を戻し、OSSの脆弱性が顕在化しにくい一番の理由は、恐らくOSSを組み込んだアプリケーションのテストにあります。

当然、機能的には全てのアプリケーションのテストは行いますし、脆弱性を発見するためのセキュリティテストも行います。

しかし、OSSなどの基本的な機能に関してのセキュリティテストにおいては、最初に行ったテスト内容やレビューを見直す機会はないのではないでしょうか。アプリケーションのバージョンアップを行ったとしても、テストはバージョンアップした機能を中心に、そして機能的なリグレッションテストが中心に行われます。

そのため、基本的な機能であるOSSに関しては、OSS自体がバージョンアップされているにも関わらず、最初のテスト内容を見直す機会はなかったのではないかと思います。このことは、アプリケーションをリリースしているベンダーもそうですが、そのアプリケーションやOSSを利用しているユーザも同じ状況であったと推察します。

OSSを利用する危険性

上記と同じ理由で、ユーザがOSSをシステムで活用することには、危険性を伴いますが、何よりもどこでOSSが利用されているのかを、ユーザが知らないという危険性もあります。

Log4jの様なOSSにおいては、そもそもそういったシステムを利用しているのかどうかを、ユーザが把握していることは稀だと思います。

もちろん、OSSを利用することで、前記の様にコストと期間の削減は可能です。

しかし、一般的にOSSはその道のプロのエンジニアが作成していると信じられていることも事実です。ビジネス的にも技術的にも合理的かつ効果的である、と疑いなくOSSを利用し続けることが最大のリスクかもしれません。

しかし、Log4jやApache HTTP Server*3といったライセンス料が無償であるOSSに脆弱性が存在することはご存じの通りです。

一般的に「ソフトウェアにバグがあるのは当たり前」と言われますが、OSSも同じです。特にApache HTTP Serverなどの複雑な機能であるOSSでは脆弱性が存在していると思うべきです。

もちろん、複雑な機能のOSSを利用するメリットはビジネス的に非常に大きいので、利用を避けるといったことは現実的ではありません。

むしろここで気にするべき問題は、OSS利用を前提としたときに自社のシステムが

①どの様なOSSを利用しているか？
②利用しているOSSに脆弱性（あるいは機能的なバグ）が存在しているかを継続して管理しているか？
③バージョンアップしたOSSを利用する際に、セキュリティテストの内容も見直しているか？

といった、通常のカスタムメイドのアプリケーションを利用する際には当たり前に行っていることを、OSSを利用するとなると、「①利用しているOSSの把握」すらも行っていないことです。

結果として、世間的にLog4jのような脆弱性の問題が発生した際に、自社のOSSが管理されていないために、システムに問題が有るのか否かが判らず、重大な影響を受ける可能性があります。さらに、OSSの機能が複雑になればなるほど、基本的な機能のOSSを利用します。

そうすると、上位のOSSで脆弱性があっても、利用されているOSSに問題があるのか、独自機能に問題があるのか判りません。つまり、利用している上位のOSSが使っている基本的なOSSに関しても知る必要があります。

そこまで含めて「①どのようなOSSを利用しているか」、「②利用しているOSSの脆弱性管理」を行っていなければ、「③OSSバージョンアップ後のセキュリティテストを実施する」ことも不可能になります。

OSSのセキュリティ対策を検討されている方へ

Morphisecの製品ページからお問合せください

OSSを利用するためにすべきこと

OSSのメリットを享受するのであれば、当然同時に存在するOSSを利用するリスクも受け入れざるを得ません。

そのリスクを最小限にするためには、前記の「①どのようなOSSを利用しているか」、「②利用しているOSSの脆弱性管理」そして「③OSSバージョンアップ後のセキュリティテストを実施する」の実施は必須です。

そうでなければ大きなリスク、つまり攻撃を受けるリスクを放置していると考えざるを得ません。

現在、ソフトウェアの部品化、オープンシステム化の流れの中で、サイバー攻撃のリスクを最小化するためにSBOM*4（Software Bill Of Materials）という概念も生まれ、いくつかの組織では、その実装がはじまりつつあります。

SBOMは、どのソフトウェアにどのようなソフトウェアを部品として利用しているかをリストとして管理します。SBOMを作成、管理していればOSSなどのソフトウェア部品に脆弱性が発見された時に、どの部分にバージョンアップ等が必要であるか即座に判ります。

ITシステムの管理には膨大な運用コストが必要になりますが、上記の理由からSBOMを採用する価値は大きいと思います。

是非とも、SBOM的アプローチをIT管理として実施する（要は、①利用しているOSSの把握を実施する）検討をお願いします。

OSSを利用するためにすべきこと

当社ができること

攻撃者は様々なプログラムに存在する脆弱性を悪用することで、プロセッサが処理するコード（プロセッサが理解できる機械語）の順序を本来のプログラムではなく、マルウェアにジャンプさせることで制御を奪います。

当社ができること

プロセス生成時、クライアントPCで稼働しているオペレーティングシステム（OS）は、読み込むプログラムファイルで指定された場所にプログラムコード領域、ヒープ領域あるいはスタック領域を割り当て、実行するプログラムを該当する領域に読み込みます。

この領域は、ソースプログラムを作成しコンパイル（ソースプログラムを機械語に変換）した後、プログラムのオブジェクトファイル作成時に決められますので、攻撃者は自分で保有しているコンピュータでプログラムを実行することで、どのメモリに展開されるかを知ることが出来ます。

当社のBlogでも複数回紹介しているMorphisecというソリューションは、Moving Target Defense技術を利用した製品で、プロセスが生成され、プログラムをメモリ上に展開するたび毎回コード領域、ヒープ領域あるいはスタック領域といったメモリ領域をランダマイズすることで、マルウェアが実行不可能な状況をつくります。

つまり、ランサムウェアなどのマルウェアが実行される前に防御する技術です。この技術の保護対象としては、OSSプログラムも含まれますので、Morphisecを利用することで、SBOMの管理やOSSのバージョンアップを行得ない場合でも、脆弱性が悪用された時に、起動したプロセスを落とす（防御）だけではなく、ユーザにマルウェアの存在を通知し、かつフォレンジック情報を提供します。

当社ができること