EMR クラスターでの Apache Log4j 2 RCE 脆弱性の修正 - E-MapReduce (EMR)

Alibaba Cloud は、Apache Log4j 2 におけるリモートコード実行 (RCE) 脆弱性を発見し、Apache Software Foundation へ報告しました。本トピックでは、影響を受ける E-MapReduce (EMR) クラスターのバージョンと、脆弱性の修正手順について説明します。

重要

クラスターが EMR V3.38.3 以降、または EMR V5.4.3 以降を実行している場合、脆弱性は既に修正済みです。対応は不要です。

影響を受けるバージョンおよびサービス

影響を受ける EMR バージョン

EMR バージョン	状態	対応の必要性
EMR V3.38.2 以前	影響あり	修正を適用
EMR V4.X	影響あり	修正を適用する
EMR V5.4.2 以前	影響あり	修正を適用する
EMR V3.38.3 以降	修正済み	なし
EMR V5.4.3 以降	修正済み	なし

影響を受けるサービス

以下のサービスが影響を受けています：Hive、Presto、Impala、Druid、Flink、Solr、Ranger、Storm、Oozie、Spark、Zeppelin。Spark および Zeppelin は、Hive への依存関係により影響を受けています。

修正処置として、クラスター上の Apache Log4j 2 JAR ファイルをバージョン 2.17.2 に置き換え、Hive および Spark の Java Naming and Directory Interface (JNDI) 検索機能を無効化するために、log4j2.formatMsgNoLookups パラメーターを true に設定します。

説明

修正スクリプトは、実行中のサービスに影響を与えません。ただし、スクリプト実行後にサービスを再起動する必要があります。そのため、非ピーク時間帯に実行してください。

既存の EMR クラスターの修正

patches-log4j.tar.gz をダウンロードします。
クラスターのマスターノードにログインし、パッケージを emr-user または hadoop ユーザーのホームディレクトリに配置します。
適切なユーザーに切り替えてパッケージを解凍します。DataLake、Dataflow、OLAP、DataServing、またはカスタムクラスターの場合：
```
su emr-user
tar zxf patches-log4j.tar.gz
```
その他のすべてのクラスタータイプの場合：
```
su hadoop
tar zxf patches-log4j.tar.gz
```
patches ディレクトリ内の hosts ファイルを開き、クラスター内の各ノードのホスト名を 1 行につき 1 つずつ追加します。
重要
EMR V3.41 以降のマイナーバージョン、または EMR V5.7.0 以降のマイナーバージョンでは、ノードのホスト名の形式が異なります：
```
core-1-1
core-1-2
task-1-1
task-1-2
```
```
cd patches
vim hosts
```
例：
```
emr-header-1
emr-worker-1
emr-worker-2
```
修正スクリプトを実行します。

説明
Spark Streaming や Flink などの YARN ジョブを実行している場合、事前にジョブを停止し、YARN NodeManager をローリングリスタートしてください。
```
./fix.sh
```
スクリプトが正常に完了すると、出力の末尾に以下が表示されます：
```
### NOTICE: YOU CAN RESTORE THIS PATCH BY RUN RESTORE SCRIPT ABOVE
$> sh ./restore.sh 20211213001755
### DONE
```
パッチをロールバックするには、以下を実行します：
```
./restore.sh 20211213001755
```
影響を受けるサービス (Hive、Hadoop 分散ファイルシステム (HDFS)、Presto、Impala、Druid、Flink、Solr、Ranger、Storm、Oozie、Spark、および Zeppelin) を再起動します。サービスを再起動するには、EMR コンソールのサービスページに移動し、右上隅にある [その他] > [再起動] を選択します。

ゲートウェイクラスターの修正

ゲートウェイクラスターはパスワードレス SSH（Secure Shell）ログインをサポートしないため、パッチを各ノードに手動で適用する必要があります。

各ノードに対して以下の操作を行います：

パッチパッケージをノードにアップロードします。
標準の EMR クラスターと同様の手順を実行します。

ゲートウェイクラスターでは、以下の 2 点に注意してください：

hosts ファイルには、全クラスターノードではなく、現在のノードのホスト名のみを記述します。
ゲートウェイクラスターにはサービスが存在しないため、パッチ適用後のサービス再起動は不要です。

クラスター作成時またはスケールアウト時の修正

新規クラスターを作成する際は、ブートストラップアクションを追加してパッチを自動適用します。既存のクラスターをスケールアウトする際は、システムが自動的に修正を適用します。その後、新しく追加されたノード上のサービスのみを再起動してください。

クラスター作成時にブートストラップアクションを設定するには、以下の手順を実行します：

patches-log4j.tar.gz および bootstrap_log4j.sh をダウンロードし、両方を Object Storage Service (OSS) のパス（例：oss://<bucket-name>/path/to/）にアップロードします。

EMR コンソールでブートストラップアクションを追加します。詳細については、「ブートストラップアクションを使用したスクリプトの実行」をご参照ください。ブートストラップアクションを以下の設定で構成します。

パラメーター	値
名前	説明的な名前（例：`fixlog4jvulnerability`
スクリプトアドレス	スクリプトファイルの OSS パス：`oss://<bucket-name>/path/to/bootstrap_log4j.sh`
パラメーター	パッチパッケージの OSS パス：`oss://<bucket-name>/path/to/patches-log4j.tar.gz`
実行範囲	クラスター
実行時間	コンポーネント起動後
実行失敗時のポリシー	続行

クラスター作成後に、以下のサービスを再起動します：HDFS、Hive、Presto、Impala、Druid、Flink、Solr、Ranger、Storm、Oozie、Spark、Zeppelin。

よくある質問

修正スクリプトは、現在実行中のサービスに影響を与えますか？

いいえ。スクリプトは実行中のサービスに影響を与えません。ただし、スクリプト実行後に影響を受けるサービスを再起動する必要があります。そのため、非ピーク時間帯に実行してください。

パッチをロールバックするにはどうすればよいですか？

修正適用時に出力された復元スクリプトを実行します：

./restore.sh 20211213001755

ゲートウェイクラスターへの修正適用は、通常と異なる方法で行う必要がありますか？

はい。ゲートウェイクラスターはパスワードレス SSH ログインをサポートしないため、パッチパッケージを各ノードに個別にアップロードし、修正スクリプトを各ノードで個別に実行する必要があります。また、ゲートウェイクラスターにはサービスが存在しないため、サービスの再起動は不要です。