Ceph MON (config-key store, MMonSubscribe handler): MULTI-TENANT ISOLATION AND HOST COMPROMISE: one crafted

Impact

MULTI-TENANT ISOLATION AND HOST COMPROMISE: one crafted MMonSubscribe message from any account with 'mon allow r' dumps the entire monitor config-key store. That store is where Ceph keeps OSD LUKS passphrases and, on cephadm-managed clusters, the SSH private key cephadm uses to reach every host in the fleet. Under the default cephadm setup that key is root-equivalent on every storage node, so a read-only monitor cap converts directly into root on the whole storage tier — and the LUKS passphrases mean an attacker who can also touch the disks gets the data at rest. 'mon allow r' is a cap operators hand out casually to monitoring agents, dashboards and tenant-facing tooling because it reads like a harmless read grant; here it is the whole cluster.

Who can reach it

Adjacent network: the attacker must reach the Ceph monitors and hold any CephX identity with 'mon allow r' capabilities. That includes most metrics collectors, dashboards, and any service account provisioned for cluster read access. No user interaction.

What to do

Upgrade to Ceph 20.2.4 or 19.2.6 and restart the monitors. Then rotate what the store held: regenerate the cephadm SSH key across the fleet and re-key OSD LUKS where feasible, because a patched monitor does not un-leak secrets already read. Audit which identities hold 'mon allow r' and cut it back to the ones that truly need it.

References