AWS ParallelCluster 3.14.1 以前の稼働中クラスターに CVE-2026-25506 対応パッチを適用してみた

AWS ParallelCluster 3.14.1 以前の稼働中クラスターに CVE-2026-25506 対応パッチを適用してみた

2026.02.17

はじめに

2026 年 2 月 17 日に AWS ParallelCluster 3.14.2 が CVE-2026-25506 対応としてリリースされました。

https://github.com/aws/aws-parallelcluster/releases/tag/v3.14.2

本件はバッファオーバーフローにより MUNGE の MAC サブキーが漏洩する脆弱性です(CVSS 7.7 High)。ローカルアクセス権を持つ攻撃者が鍵を抽出し、root を含む任意ユーザーの認証情報を偽造できる可能性があります。MUNGE を 0.5.18 にアップグレードすることで対処できます。

https://github.com/dun/munge/security/advisories/GHSA-r9cr-jf4v-75gh

しかし、運用中のクラスターをすぐに切り替えられないケースもあります。本記事では、3.14.1 以前で稼働中のクラスターにパッチを適用する手順を紹介します。

手順は AWS 公式の Wiki を参考にし試してみました。

https://github.com/aws/aws-parallelcluster/wiki/Upgrade-MUNGE-in-a-running-cluster

対応の概要

もっと手軽な方法でパッチ充てを検討した結果、対応は以下の 2 ステップです。

  1. ヘッドノードで MUNGE 0.5.18 をビルド・インストールする
  2. コンピュートノードにカスタムアクションでパッチを配布する

検証環境

項目
リージョン ap-northeast-1
ParallelCluster 3.14.0
OS Ubuntu 24.04
MUNGE(アップグレード前) 0.5.16

ヘッドノードのアップグレード

検証用のクラスターを用意しました。

インスタンス___EC2___ap-northeast-1-3.png

現在のバージョン確認

現在の MUNGE バージョンを確認します。

munged --version

予定どおり脆弱性を抱えているバージョンです。

実行結果
munge-0.5.16 (2024-03-15)

既存ファイルのバックアップ

アップグレード前に既存の MUNGE 関連ファイルをバックアップします。

MUNGE_FILES=(
  /etc/munge/
  /usr/bin/munge
  /usr/bin/remunge
  /usr/bin/unmunge
  /usr/sbin/mungekey
  /usr/sbin/munged
  /usr/lib/systemd/system/munge.service
  /usr/lib*/libmunge*
)

sudo rsync -aR "${MUNGE_FILES[@]}" /opt/parallelcluster/sources/munge-backup

MUNGE 0.5.18 のビルドとインストール

MUNGE 0.5.18 のソースをダウンロードします。

MUNGE_VERSION="0.5.18"
sudo mkdir -p /opt/parallelcluster/sources
sudo curl -fsSL -o /opt/parallelcluster/sources/munge-${MUNGE_VERSION}.tar.xz \
  https://us-east-1-aws-parallelcluster.s3.us-east-1.amazonaws.com/archives/dependencies/munge/munge-${MUNGE_VERSION}.tar.xz
sudo tar -xvf /opt/parallelcluster/sources/munge-${MUNGE_VERSION}.tar.xz -C /opt/parallelcluster/sources
cd /opt/parallelcluster/sources/munge-${MUNGE_VERSION}

OS に応じたライブラリディレクトリを設定し、ビルド・インストールします。

grep -qi ubuntu /etc/os-release && MUNGE_LIBDIR="/usr/lib" || MUNGE_LIBDIR="/usr/lib64"
sudo ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=${MUNGE_LIBDIR}
sudo make install

MUNGE サービスの再起動

sudo systemctl daemon-reload
sudo systemctl restart munge

動作確認

アップグレード後のバージョンを確認します。

munged --version

脆弱性対処済みのバージョンになりました。

実行結果
munge-0.5.18 (2026-02-10)

MUNGE サービスの稼働状態を確認します。

sudo systemctl status munge
実行結果
● munge.service - MUNGE authentication service
     Loaded: loaded (/usr/lib/systemd/system/munge.service; enabled; preset: enabled)
     Active: active (running) since Mon 2026-02-16 23:52:52 UTC; 14s ago
       Docs: man:munged(8)
    Process: 21491 ExecStart=/usr/sbin/munged $OPTIONS (code=exited, status=0/SUCCESS)
   Main PID: 21495 (munged)
      Tasks: 4 (limit: 2275)
     Memory: 1.3M (peak: 1.7M)
        CPU: 17ms
     CGroup: /system.slice/munge.service
             └─21495 /usr/sbin/munged

MUNGE の認証動作を確認します。

sudo munge -n | unmunge

STATUS: Success (0) が表示されれば成功です。

実行結果
STATUS:          Success (0)
ENCODE_HOST:     ip-10-0-0-131.ap-northeast-1.compute.internal (10.0.0.131)
ENCODE_TIME:     2026-02-17 00:46:40 +0000 (1771289200)
DECODE_TIME:     2026-02-17 00:46:40 +0000 (1771289200)
TTL:             300
CIPHER:          aes128 (4)
MAC:             sha256 (5)
ZIP:             none (0)
UID:             root (0)
GID:             root (0)
LENGTH:          0

Slurm でジョブが実行できることも確認しますと手順にあったのですが、何も結果が返ってきませんでした。

srun hostname

コンピュートノードのアップグレード

コンピュートノードには、ヘッドノードでビルドしたバイナリをカスタムアクションで配布します。

バイナリの共有ディレクトリへのコピー

ヘッドノードでビルドした MUNGE バイナリを共有ディレクトリにコピーします。

MUNGE_FILES=(
  /usr/bin/munge
  /usr/bin/remunge
  /usr/bin/unmunge
  /usr/sbin/mungekey
  /usr/sbin/munged
  /usr/lib/systemd/system/munge.service
  /usr/lib/sysusers.d/munge.conf
  /usr/lib*/libmunge*
)

sudo rsync -aR "${MUNGE_FILES[@]}" /opt/parallelcluster/shared/.munge/

カスタムアクションスクリプトの作成

コンピュートノード起動時にバイナリを配布するスクリプトを作成します。

PatchMunge.sh
#!/bin/bash
set -ex
sudo rsync -a /opt/parallelcluster/shared/.munge/usr/ /usr/
sudo systemctl daemon-reload

作成したスクリプトを S3 バケットにアップロードします。S3 バケットの名前(devio-custom-boostrap-files)はご自身の環境に置き換えてください。

aws s3 cp PatchMunge.sh s3://devio-custom-boostrap-files/patch-munge/PatchMunge.sh

クラスター設定の更新

クラスター設定ファイルの SlurmQueues に S3 アクセス権限と OnNodeStart カスタムアクションを追加します。

Scheduling:
  Scheduler: slurm
  SlurmQueues:
    - Name: queue-name
      # ... 既存の設定 ...
      Iam:
        S3Access:
          - BucketName: devio-custom-boostrap-files
            EnableWriteAccess: False
      CustomActions:
        OnNodeStart:
          Script: s3://devio-custom-boostrap-files/patch-munge/PatchMunge.sh

S3Access で S3 バケットへの読み取り権限を付与しています。カスタムアクションスクリプトの取得に必要な設定です。

クラスターの更新と再起動

コンピュートフリートを停止し、クラスター設定を更新した後、フリートを再起動します。

フリートの停止・開始手順は以下の記事を参考にしてください。

https://dev.classmethod.jp/articles/how-to-update-parallelcluster-for-fish/

コンピュートノードの動作確認

テストジョブをサブミットしてコンピュートノードを起動します。

インスタンス___EC2___ap-northeast-1-4.png

コンピュートノードにログインし、MUNGE のバージョンを確認します。

sudo su - ubuntu
munged --version

脆弱性対処済みのバージョンになりました。

実行結果
munge-0.5.18 (2026-02-10)

コンピュートノードでも MUNGE 0.5.18 に更新されたことを確認できました。

まとめ

ParallelCluster 3.14.1 以前の稼働中クラスターで CVE-2026-25506 に対応する方法を紹介しました。ヘッドノードで MUNGE をビルド・インストールし、コンピュートノードにはカスタムアクションで配布します。

おわりに

今回のパッチ充て作業は地味に手間でした。クラスターの管理に不慣れなら ParallelCluster 3.14.2 でクラスターを新規作成し、移行する方を推しておきます。この様な運用作業は PCS(Parallel Computing Service)d だと AWS さんが管理してくれるので楽で良いかもしれないですね。

この記事をシェアする

FacebookHatena blogX

関連記事