From ${URL} : Ceph monitors crash when an empty prefix is sent to mon_command by rados.py. User who has access to rados can crash ceph monitors by sending empty prefix to mon_command via rados.py. upstream fixes: https://github.com/ceph/ceph/pull/9700 https://github.com/ceph/ceph/commit/957ece7e95d8f8746191fd9629622d4457d690d6 @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Fixed for 9.2 and 10.2 series: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4c6618086e16e704df31113b279e7ea4395bd41a Current patch does not apply to older 0.80 and 0.94 series
Arches, please test and mark stable: =sys-cluster/ceph/ceph-9.2.1-r2 Target keywords: "amd64 x86" Note: this bug depend on 586128
amd64 stable
x86 stable. Maintainer(s), please cleanup. Security, please vote.
Cleanup done.
CVE-2016-5009 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2016-5009): A flaw was found in the way handle_command() function would validate prefix value from user. An authenticated attacker could send a specially crafted prefix value resulting in ceph monitor crash.
GLSA Vote: No
Is removing 0.94.x package the right solution here ? I'm surprised that a supported LTS version (0.94.x aka Hammer is LTS and is still supported upstream) doesn't have a patch available for CVE-2016-5009. Removing Hammer packages when Firefly was the last stable version removes any upstream supported upgrade path (only Firefly -> Hammer -> Jewel is supported). Has anyone verified that the Firefly -> Infernalis upgrade works on Gentoo ? I ask because just before 0.80.10-r1 was removed it was reinstalled on several of our existing 0.80 installation (due to a USE flag change, as we removed "xfs") and the init scripts wanted all processes to run as a ceph user (which was not created) after that (init.d file was changed to start processes as the ceph user). Running as ceph is how upstream advise Ceph to run for later version but this wasn't the case for Firefly. I had to manually create the user and chmod all files to start 0.80.10-r1 processes. This was not a big problem, but not one that I expected, especially as the first daemon restart was not done until several days after the reinstall. I have new servers to install on our Ceph cluster and given : - no upstream support for 0.80.x to 9.2.x upgrade, - this past init.d glitch, I'd like to be sure that migrating everything to a version not supported upstream anymore (which is the only path available right now) will at least be supported by Gentoo devs. So was the upgrade tested ? Or is a 0.94.x package in the works ?
Extract from the Infernalis (9.2.x) release announcement -- BEGIN -- Upgrading directly from Firefly v0.80.z is not recommended. It is possible to do a direct upgrade, but not without downtime. We recommend that clusters are first upgraded to Hammer v0.94.4 or a later v0.94.z release; only then is it possible to upgrade to Infernalis 9.2.z for an online upgrade (see below). -- END -- We use Ceph to avoid downtime of our VMs, so we'll have to fetch an Hammer ebuild from archives if Gentoo doesn't package it. In the current situation users who aren't aware of the upgrade limitations might have a very difficult time when they try to update their clusters and VMs crash/freeze...
Hammer fix has been merged in the hammer branch (so a 0.94.7 with this patch or the future 0.94.8 will not be affected) : https://github.com/ceph/ceph/pull/10038 I'm not sure if I should open another bug about the lack of no-downtime upgrade path for current Gentoo Ceph installations and pointing to this patch or if someone should reopen this bug. From a security point of view the bug is fixed but from an usability point of view Ceph is broken by the fix.
hi Lionel Bouton, we decide to keep at least two LTS[0] versions in tree, which means I will get hammer (0.94.x) back, this should address your problem. thanks for bringing this up [0] http://docs.ceph.com/docs/master/releases/
