どうも、Tです。
2021年12月にApache Log4jの脆弱性が見つかりCVSSスコア10.0とトップの数値をたたき出し世界を恐怖に陥れました。
VMware製品もLog4jの脆弱性に関する製品が多数存在し、今回はvCenterの脆弱性に対する暫定対応方法を試してみました。
VMware製品に関してのアドバイザリーは下記にまとめられています。
2022年7月追記
下記KBで本問題は解決されています。解決バージョンへアップグレードする場合は、本記事の手順は不要です。
Resolution
This issue is resolved in:vCenter Server 7.0 Update 3c, build 19234570.
vCenter Server 6.7 Update 3q, build 19300125
vCenter Server 6.5 Update 3s, build 19261680Please note that it is not necessary to revert the workaround steps in this article before upgrading to a fixed release of vCenter Server.
Do not use the vc_log4j_mitigator.py script on vCenter Servers that have already been upgraded to a fixed version, such as 7.0 U3c.
目次
環境
- VMware vCenter Server 7.0 Update 2d（18455184）
やりたいこと
暫定対応
下記のKBを参考にvCenterのLog4jの暫定対応を行います。
暫定対応には、「Automated(自動)※推奨方法」「Manual(手動)」の2つのパターンがありますが、推奨方法であるAutomatedを実施してみます。
ちなみに、vCenterがあれば必ず存在するであろう「VMware vSphere ESXi」「VMware Tools」は、影響はないと発表されています。（2022年1月現在）
Products NOT impacted by CVE-2021-44228 and CVE-2021-45046:
- VMware vSphere ESXi
- VMware Tools
恒久対応（参考）
本記事では触れませんが、恒久対応としては、「vCenter Server 7.0 Update 3c」へのアップデートになります。
リリースノートには、下記のように説明されています。
Security Issues
vCenter Server 7.0 Update 3c delivers the following security updates:
- The Spring package in the vSphere Client is updated to version 5.2.4.
- Apache Struts is updated to version 2.5.28.3.
- vCenter Server 7.0 Update 3c updates Apache httpd to address CVE-2021-40438. VMware would like to thank Saeed Kamranfar of Sotoon Security for alerting on this issue.
- Apache log4j is updated to version 2.17 to resolve CVE-2021-44228 and CVE-2021-45046. For more information on these vulnerabilities and their impact on VMware products, please see VMSA-2021-0028.
vCenter6.x系の対応パッチはまだ出ていないようです（2022年1月現在）。
前提条件
下記KBのvc_log4j_mitigator.pyを利用したAutomated方法を実施します。
注意事項があるのでさらっとまとめておきます。
- この手順で対応できるのは、vCneter7.x、6.7.x、6.5.xである
- VCHA構成では実施できない。VCHAを削除して本手順後に再構成する必要がある
- vCenterファイルベースバックアップから復元後は、再度本手順を実施する必要がある
- vCenterをアップグレード後は、再度本手順を実施する必要がある
本手順の内容はあくまで暫定的な一時対応になります。
恒久対応は、vCenter Server 7.0 Update 3cへアップグレードしてください。
vCenter6.x系は恒久対応のパッチがでていないため、公開されるまでお待ちください。（2022年1月）
Log4j暫定対応（Automated）
vc_log4j_mitigatorダウンロード
KBのAttachmentsから「vc_log4j_mitigator」をクリックしてダウンロードします。
「vc_log4j_mitigator.py」がダウンロードできました。
Attachmentsに「remove_log4j_class」がありますが、「vc_log4j_mitigator」が公開される前に、KB87088と合わせて利用するものでした。
現在KB87088では、「vc_log4j_mitigator」を使う方法を案内してお「remove_log4j_class」をダウンロードする必要はありません。
vc_log4j_mitigatorをvCenterへアップロード
「vc_log4j_mitigator.py」をvCenterへアップロード(今回は/tmp)します。デフォルト状態ではvCenterへSFTP接続できないため、下記の記事を参考にしてください。
dryrunで脆弱性確認
下記のコマンドを実行して脆弱性のあるプログラムファイルを確認します。数分程度必要かかりました。「–dryrun」は「-r」オプションと同じ意味になります。
python vc_log4j_mitigator.py --dryrun
長いため割愛していますが、脆弱性に該当するjarやwarファイルのリストが表示されます。
root@testvcsa [ /tmp ]# python vc_log4j_mitigator.py --dryrun 2022-01-28T14:35:14 INFO main: Script version: 1.6.0 2022-01-28T14:35:14 INFO main: vCenter type: Version: 7.0.2.00500; Build: 18455184; Deployment type: embedded; Gateway: False; VCHA: False; Windows: False; 2022-01-28T14:35:14 INFO main: Running in dryrun mode. 2022-01-28T14:35:30 INFO process_jar: Found a VULNERABLE FILE: /opt/vmware/lib64/log4j-core-2.13.0.jar 2022-01-28T14:35:32 INFO process_jar: Found a VULNERABLE FILE: /storage/updatemgr/jetty-temp/jetty-127_0_0_1-9085-vum-filedownload_war-_vum-filedownload-any-7967433058027383293/webapp/WEB-INF/lib/log4j-core-2.13.3.jar -長いため割愛- Total found: 19 Log file: /var/log/vmsa-2021-0028_2022_01_28_05_35_14.log =========================== 2022-01-28T14:36:10 INFO main: Done.
vc_log4j_mitigatorの実行(vCenterサービス自動停止)
「–dryrun」オプションを外した下記コマンドを実行します。vCenterサービスが停止しますので注意してください。数分程度かかりました。
python vc_log4j_mitigator.py
KBの説明では、上記の処理で各jar/warファイルから、脆弱性となっているJndiLookup.classを削除しているようです。
処理が終わるとvCenterサービスが自動的に起動します。（ここまで5分程度）
dryrunで脆弱性対応確認
再度、–dryrunオプションをつけて下記コマンドを実行します。
python vc_log4j_mitigator.py --dryrun
「0」と表示されて問題となるファイルがないことが確認できました。
root@testvcsa [ /tmp ]# python vc_log4j_mitigator.py --dryrun 2022-01-28T14:49:21 INFO main: Script version: 1.6.0 2022-01-28T14:49:21 INFO main: vCenter type: Version: 7.0.2.00500; Build: 18455184; Deployment type: embedded; Gateway: False; VCHA: False; Windows: False; 2022-01-28T14:49:21 INFO main: Running in dryrun mode. 2022-01-28T14:50:17 INFO print_summary: ===== Summary ===== No vulnerable files found! Total found: 0 Log file: /var/log/vmsa-2021-0028_2022_01_28_05_49_21.log =========================== 2022-01-28T14:50:17 INFO main: Done.
最初の–dryrunで確認したファイル数が19なのに、実行後のファイル数は16になっているのがいささか不可思議ではありますが、最終的な結果が0なんで大丈夫なんでしょうね・・・・。
その他
今回参考にしたKBに下記の記述あがり、vc_log4j_mitigator.pyを実行してもサードパーティのvSphere Clientプラグインは脆弱性であると検出されるようです。（クライアント起動毎にjarファイルを生成するためJndiLookup.classを削除しても意味ないっぽいですね）
Note: Certain 3rd party vSphere Client plugins may be detected as vulnerable even after remediation is done. This is because the jar files are recreated each time the client is started. These must be addressed by either patching the plugin to an unaffected version, marking it incompatible, or removing the plugin via the vCenter MOB. Disabling the plugin from the vSphere Client will not work.
この問題は、vSphere Client上からプラグインを無効にしても解決されず、対処方法として、下記が案内されています。プラグインをバージョンアップするパターンが一番現実的ですね。
| パターン | 参考 | 備考 |
| プラグインの脆弱性対応バージョンへアップデート | ー | 恒久対応 （プラグインの利用可能） |
| 互換性がないことのマーク | KB83829 | 暫定対処 （プラグインの利用不可） |
| MODを介したプラグインの削除 | KB1025360 | 暫定対処 （プラグインの利用不可） |
まとめ
vCenter7のLog4jへの対応パッチなかなかでないため、急な要望が来た時用に検証してみましたが、この記事を書いている間に対応バージョンのvCenter7.0.3cがリリースされてました・・・・。
リリースされたばかりで、バグを引いたりすることを考えると、暫定対応して少し待ってからvCenter7.0.3cへバージョンアップかなぁ。