When creating a file, open()/creat() allows the setgid bit to be set
via the mode argument even when, due to the bsdgroups mount option or
the file being created in a setgid directory, the new file's group is
one which the user is not a member of. The user can then use
ftruncate() and memory-mapped I/O to turn the new file into an
arbitrary binary and thus gain the privileges of this group, since
these operations do not clear the setgid bit.
Created attachment 11377 [details]
Python script to reproduce
When run in a setgid directory, this should produce a copy of
/usr/bin/id that is setgid to the directory group, regardless of
whether the user belongs to it. I've verified this on the ext2, ext3,
ReiserFS, XFS, JFS and tmpfs file systems.
I believe this was fixed in :
Author: Linus Torvalds <email@example.com>
Date: Tue May 8 20:10:00 2007 -0700
Remove suid/sgid bits on [f]truncate()
.. to match what we do on write(). This way, people who write to files
by using [f]truncate + writable mmap have the same semantics as if they
were using the write() family of system calls.
Signed-off-by: Linus Torvalds <firstname.lastname@example.org>
If you concur please close?
(In reply to comment #2)
> I believe this was fixed in :
> commit 7b82dc0e64e93f430182f36b46b79fcee87d3532
> Author: Linus Torvalds <email@example.com>
> Date: Tue May 8 20:10:00 2007 -0700
> Remove suid/sgid bits on [f]truncate()
Thanks Eric. I have tested this. This patch fixes the problem, and prevents the possible disclosure of privileged information.