On Tue, 02 Feb 2021 at 17:06:15 +0100, Guillem Jover wrote:
> This also affects msmtp when using its Secret Service support. Its
> debugging output is not great by default (need to send a patch for
> that), but once trapping the GError from the libsecret calls, it
> mentions that it cannot spawn a message bus due to the binary being
> set-UID root.
Is msmtp really setuid root, or are you paraphrasing an error message?
The error messages that GIO emits in these situations say "setuid" for
brevity, but what they really mean is "setuid, setgid, setcap, anything
else that triggers AT_SECURE on Linux, or the equivalent on other OSs".
Looking at source code, it seems the postinst makes msmtp setgid rather
than setuid - although that's maybe equally problematic from the point
of view of making msmtp not be exploitable.
As with gnome-keyring-daemon, I suspect that until this recent GIO
change, msmtp could be tricked into executing arbitrary code with its
elevated privilege. For gnome-keyring-daemon that's CAP_IPC_LOCK, which
is a relatively uninteresting privilege when we accidentally give all our
users a very high RLIMIT_MEMLOCK anyway (see recent discussion on -devel).
For msmtp it's access to whatever the msmtp group can do, which from its
documentation seems to mean ability to read passwords out of /etc/msmtprc.
That seems quite bad?
The security hardening change in GIO was to stop trusting any
environment variables to have non-malicious values if the process is
a setuid/setgid/setcap executable. This was considered to be hardening
rather than a vulnerability fix, because GIO is not documented as having
been designed to be safe to use in a setuid/setgid/setcap process without
first sanitizing the execution environment - but people sometimes use it
like that anyway (as in msmtp, apparently).
The root cause here is that having elevated privileges that ordinary user
processes aren't allowed to have, and being on the D-Bus session bus (where
the security model is that every connected process is equally trusted and
the discovery mechanism relies on environment variables), are not really
compatible.
One of the workarounds I was considering applying was to make GIO only
ignore DBUS_SESSION_BUS_ADDRESS if it is actually *setuid*, and be willing
to use DBUS_SESSION_BUS_ADDRESS (even though in principle we shouldn't) if
the program that is using GIO is AT_SECURE but not actually setuid. That's
wrong, but less wrong than with older versions of GIO... but it would
potentially still leave msmtp vulnerable to attacks in which an unprivileged
user gets arbitrary code executed with the privileges of the msmtp group.
Sorry, I don't have a good solution for this. The two bad solutions are
to keep the change (making gnome-keyring and msmtp regress), or revert it
(making gnome-keyring and msmtp probably exploitable). Do you have any
better ideas?
The way to make this secure would be for the part of msmtp that exercises
the group msmtp's privileges, and the part that interacts with complicated
libraries like libsecret, to be separate processes - but that's a
significant design change.
smcv
