2022年11月のOpenSSL脆弱性対策にSysdig Secureを活用する

By 清水 孝郎 - OCTOBER 31, 2022

SHARE:

Falco

本文の内容は、2022年10月30日にEduardo Mínguezが投稿したブログ(https://sysdig.com/blog/sysdig-prepare-november-2022-openssl-vulnerability/)を元に日本語に翻訳・再構成した内容となっております。

この記事は作業中のブログ記事です。より多くの情報が入手可能になり次第、更新されます。
本脆弱性の詳細については、「OpenSSLの重大な脆弱性が人気のコンテナイメージに与える影響について」のブログ記事をご覧ください。

11月1日にOpenSSLプロジェクトにおいて、CVSSスコアの深刻度が「high」または「critical」と予想される重大な脆弱性が発表されようとしています。10月25日にOpenSSLのメーリングリストにこんな発表があったほかは、まだ詳細は不明です。

こんにちは、
OpenSSLプロジェクトチームは、OpenSSLバージョン3.0のリリースを間近に控えていることを発表したいです。
OpenSSL プロジェクトチームは、OpenSSL バージョン 3.0.7 のリリースを発表します。
このリリースは2022年11月1日(火)13:00-17:00 UTCに利用可能になる予定です。
1300-1700 UTCに公開されます。
OpenSSL 3.0.7は、セキュリティ修正リリースです。このリリースで修正された最も重要度の高い問題
このリリースで修正された最も重要な問題はCRITICALです。
https://www.openssl.org/policies/general/security-policy.html
さよなら
OpenSSL プロジェクトチーム

この脆弱性の重大度評価、OpenSSL の共通性、および OpenSSL の脆弱性に広く影響を与える過去の歴史を考慮すると、できるだけ早くソフトウェアを更新する準備をしておくことが望まれます。

OpenSSLバイナリだけに影響するのか、OpenSSLライブラリにも影響するのかは不明です。さらに複雑なことに、LinuxディストリビューションによってOpenSSLライブラリの名称が異なり、Debianベースのディストリビューションではlibssl、RPMベースではopenssl-libsという名称が使用されています。

OpenSSLv3 は Node.j v18.x および v.19.x のパッケージバージョンにも含まれており、他の依存関係の中にネストされていたり遷移していたりすることがあるので、すぐにわかるものよりも多くのインスタンスがあることが予想されます。

この記事では、Sysdig Secureを使用して、環境内のOpenSSLを含むコンテナイメージのインベントリを生成する方法について説明します。このインベントリは、経営陣への報告や、避けられない修復作業に対するチームの優先順位付けと連携に役立ちます。

準備作業

CVE IDはまだ公開されていませんが、レポート機能を使用して、環境内の特定の脆弱なパッケージとバージョンを探すことができます。

前述したように、LinuxディストリビューションによってOpenSSLライブラリの名称が異なり、Debianベースのディストリビューションではlibssl、RPMベースではopenssl-libsという名称が使用されています。すべてのケースをカバーするために、2種類のレポートを作成する必要があります。1つは “openssl” を含むパッケージ名で、もう1つは “libssl” で始まるパッケージ名で、それぞれ作成します。レポートの作成方法の詳細については、公式ドキュメントを参照してください。

パッケージ名が「Node.js」でバージョンが「18」で始まるもの、パッケージ名が「Node.js」でバージョンが「19」で始まるもの、それぞれについてレポートを作成します。

“Vulnerability” -> “Reporting”で、影響を受ける可能性のあるOpenSSLパッケージ(バージョン3)を探すためのレポートを作成してみましょう。


そして、”Add a report “ボタンを選択します。


求めるレポートは以下の通りです:



この条件を利用して、OpenSSLを含むパッケージ名を持ち、パッケージのバージョンが3で始まるコンテナイメージを表示させたいと思います。

先に説明したように、この脆弱性はバージョン3.0.Xにのみ影響します。

次に、「Preview」ボタンを押すと、レポートのプレビューが表示されます。

また、“Vulnerability” -> “Reporting”でレポートを選択し、 “Generate now” ボタンを押せば、手動でレポートを生成することも可能です:



数秒後(環境により異なります)、レポートがダウンロードできるようになります。



この場合、イメージ名とバージョン、Kubernetesコンテキスト(K8Sクラスター名、K8Sネームスペース名、K8Sワークロードタイプ、K8Sワークロード名、K8Sコンテナ名)を含むすべての情報が含まれるCSVファイル(JSONまたはNDJSONファイルでも可能)です。

CSVファイルは、例えばLibreOfficeで開くことができ、すべての詳細情報を得ることができます。


この例は、OpenSSLパッケージについてだけであることを忘れないでください。

レガシーエンジンを使う場合

レガシーエンジンを使用する場合も、手順はよく似ています(詳しくは公式ドキュメントをご覧ください)。パッケージ名「openssl」、パッケージ名「libssl」、パッケージ名「Node.js」に対して、同様のレポートを作成します。

今回は、“Vulnerabilities” -> “Scheduled reports”でレポートを作成します。



そして、”Add a report “ボタンを選択します。


前述に説明したようにデータを入力しますが、今回は「OpenSSL」というパッケージが含まれるイメージをフィルタリングすることが条件となります。以下、簡単な3ステップで適用できます。

レポートの作成


条件を追加する(パッケージ名のみ、パッケージのバージョンはCSV/JSONファイルで直接フィルタリング可能)。



プレビューと保存



スケジュールして実行すると、設定したメールに送信されるだけでなく、ダウンロードも可能になります。

この場合、イメージ名やバージョン、Kubernetesのコンテキスト(K8Sクラスター名、K8Sネームスペース名、K8Sワークロードタイプ、K8Sワークロード名、K8Sコンテナ名)を含む、利用できるすべての情報を含むCSVファイル(JSONファイルでも可能)です。


CSVファイルは、例えばLibreOfficeで開くことができ、すべての詳細を取得し、必要なパッケージのバージョンでフィルタリングすることができます。



今後、より多くの情報が入手可能になり次第、内容を更新していく予定です。