Database/Control plane, storage & DevOps
MUNGE (munged credential daemon): MULTI-TENANT ISOLATION: This is the root of trust under Slurm. A crafted message with
Impact
MULTI-TENANT ISOLATION: This is the root of trust under Slurm. A crafted message with an oversized address-length field overflows a buffer in munged and lets a local attacker read the MAC subkey out of the daemon's memory. With that key they forge MUNGE credentials for any identity, including root, to every service on the cluster that trusts MUNGE - which on a Slurm site is slurmctld, slurmd and slurmdbd. A researcher PoC demonstrated key extraction with ASLR, PIE, NX and RELRO all enabled.
Who can reach it
A local user on any node running munged - i.e. any tenant with a job on a compute node. The forged credentials are then usable cluster-wide, so a foothold on one node becomes authority over the whole scheduler.
What to do
Upgrade MUNGE to 0.5.18 on every node. Then regenerate the MUNGE key: stop munged cluster-wide, run mungekey --create --force as the munge user on one node, push the new key to all nodes, restart munged. Key regeneration means an all-node munged stop, so running jobs that need to re-authenticate will break - schedule a window. Patching alone is not sufficient if you believe the key was already extracted.
References
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.