[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3a4fb353-f4c2-4c76-9958-42714c2946eb@gmail.com>
Date: Thu, 26 Jun 2025 19:55:06 -0500
From: Jacob Bachmeyer <jcb62281@...il.com>
To: oss-security@...ts.openwall.com,
"Sage [They / Them] McTaggart" <amctagga@...hat.com>
Subject: Re: CVE-2025-52555 Ceph: CephFS Permission Escalation
Vulnerability in Ceph Fuse mounted FS
On 6/26/25 15:09, Sage [They / Them] McTaggart wrote:
> Hello all,
> A flaw was found in CephFS. An unprivileged user can escalate to root
> privileges in a ceph-fuse mounted CephFS by chmod 777 a directory owned by
> root to gain access.
>
> [...]
>
> It is patched via 17.2.8 <https://github.com/ceph/ceph/pull/60314> , 18.2.5,
> and 19.2.3 in upstream Ceph.
From that patch:
bool allowed = false;
[...]
if ((in->mode & (S_ISUID | S_ISGID)) != (stx->stx_mode & (S_ISUID |
S_ISGID)) &&
(in->mode & ~(S_ISUID | S_ISGID)) == (stx->stx_mode & ~(S_ISUID
| S_ISGID))) {
allowed = true;
}
[...]
if (perms.uid() != 0 && perms.uid() != in->uid && !allowed)
goto out;
Am I misreading the code or missing context or does this allow *any*
change to the SUID/SGID bits, provided that the other mode bits are not
simultaneously changed? Is there some other check before this code is
reached that prevents Alice from making Bob's (or root's...) o+x
executable set-id and then running it?
If I correctly understand the description of the problem---that an
unprivileged user was able to chmod root-owned directories---how is this
patch not introducing another problem of permitting unprivileged users
to tweak set-id bits on other users' files?
Maybe the correct answer is to not allow chmod except for root and the
file's owner?
-- Jacob
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
