|Summary:||<sys-cluster/glusterfs-4.1.5: Privilege escalation via gluster_shared_storage when snapshot scheduling is enabled (CVE-2018-1088)|
|Product:||Gentoo Security||Reporter:||Thomas Deutschmann (RETIRED) <whissi>|
|Component:||Vulnerabilities||Assignee:||Gentoo Security <security>|
|Whiteboard:||C1 [glsa+ cve]|
|Runtime testing required:||---|
Description Thomas Deutschmann (RETIRED) 2018-04-12 21:28:01 UTC
Comment 1 James Le Cuirot 2018-05-26 11:48:27 UTC
I'm not sure but if this only affected 3.x then I think we're good now.
Comment 2 Thomas Deutschmann (RETIRED) 2018-06-22 11:01:52 UTC
When certain options are enabled in Gluster, it creates a volume called gluster_shared_storage. This volume is mounted on each server in the cluster and used to share state. The volume is not intended to be mounted by storage clients as it does not contain any data that is intended to be user accessible. When snapshot scheduling is enabled in Gluster, this gluster_shared_storage volume is used to coordinate the snapshots. Part of that is sharing the cron job that is used to trigger scheduled snaps. The crontab file exposed in the shared volume is symlinked into each server's /etc/cron.d directory. By default, the shared_storage volume can be mounted by any client that has access to the cluster to mount data volumes. Further, since Gluster relies on client-reported uids, the shared_storage volume can be written from any of these clients, permitting cron entries to be added to the system crontab directory such that they will be executed by each server as root (or any other uid). Snapshot scheduler is disabled by default after initialization. https://review.gluster.org/#/c/19899/ https://review.gluster.org/#/c/19898/ When fixing the issue it's important to not apply the incomplete fix and open CVE-2018-1112 causing that auth.allow allows all clients to mount volumes. Cf. https://bugzilla.redhat.com/show_bug.cgi?id=1570891 Needs: https://review.gluster.org/#/c/19899/1..2
Comment 3 Thomas Deutschmann (RETIRED) 2018-06-22 11:02:14 UTC
*** Bug 655546 has been marked as a duplicate of this bug. ***
Comment 4 Aaron Bauman (RETIRED) 2018-12-02 17:12:47 UTC
@arches, please stabilize. targeting 4.1.5
Comment 5 Mikle Kolyada 2018-12-02 18:05:58 UTC
Comment 6 Sergei Trofimovich (RETIRED) 2018-12-08 10:23:29 UTC
Comment 7 Sergei Trofimovich (RETIRED) 2018-12-08 10:55:32 UTC
Comment 8 Thomas Deutschmann (RETIRED) 2018-12-09 23:52:11 UTC
Comment 9 Tomáš Mózes 2019-03-19 06:17:42 UTC
Seems like that by accident 4.0.2 got stabilized on amd64 while the rest stabilized 4.1.5.
Comment 10 Agostino Sarubbo 2019-03-19 13:04:24 UTC
amd64 stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
Comment 11 Yury German 2019-03-24 12:20:20 UTC
Maintainer(s), please drop the vulnerable version(s): 4.0.2, 4.0.0-r1 New GLSA Request filed.
Comment 12 GLSAMaker/CVETool Bot 2019-04-02 04:27:51 UTC
This issue was resolved and addressed in GLSA 201904-06 at https://security.gentoo.org/glsa/201904-06 by GLSA coordinator Aaron Bauman (b-man).
Comment 13 Yury German 2019-04-02 07:22:38 UTC
Reopening for cleanup. Maintainer(s), please drop the vulnerable version(s).
Comment 14 Aaron Bauman (RETIRED) 2019-04-02 21:13:54 UTC
(In reply to Yury German from comment #13) > Reopening for cleanup. > Maintainer(s), please drop the vulnerable version(s). Cleanup will happen in bug #670088 after final stables...