On 2021-02-03 7:26 a.m., Simon McVittie wrote:
On Tue, 05 Nov 2019 at 10:02:23 -0500, Simon Deziel wrote:
On 2019-11-05 9:29 a.m., Jakub Wilk wrote:
If /etc/msmtprc is readable by group msmtp (as suggested in
README.Debian), any user can acquire password from that file
Nice catch! Having /etc/msmtprc group readable is AFAIK, a "debianism".
I don't know if upstream endorses this method of restricting access
to the default account's password.
Even if this specific attack did not exist, if msmtp is not specifically
Right, I'll be ignoring this (upstream) fixable problem for the sake of
discussion.
designed to be safe to use with elevated privileges, then I think it's
a security-significant, Debian-specific bug to be making it setgid
in Debian.
Privileged (setuid/setgid/setcap) executables need to be written in a
defensive/paranoid way. They have to be specifically designed to distrust
their whole execution environment - environment variables, command-line
options, resource limits and so on - and every library they are linked
to needs to be specifically designed to do the same. Otherwise, there is
often a way for an attacker to trick the process into executing arbitrary
code with its elevated privileges, which gives the attacker access to
those elevated privileges. Please see
<https://dwheeler.com/secure-programs/Secure-Programs-HOWTO.html> for
a lot more information on this topic.
In this case, the elevated privilege is the ability to read files that
are 0640 root:msmtp, such as /etc/msmtprc in the configuration suggested
by Debian-specific documentation in this package.
This came to my attention because I was recently involved in hardening
GLib so that it is more difficult to use as an attack vector to get
elevated privileges like this. This made GLib distrust environment
variables, which ended up breaking msmtp's support for retrieving
passwords from libsecret
(see <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981420#59>,
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981420#71>).
Note that GLib is not really designed to be used in processes that run
with elevated privileges, so the GLib upstream maintainers consider this
to be security hardening to mitigate it being used in an unsafe way,
rather than a fix for a vulnerability in GLib.
For now, GLib upstream has partially reverted that change, weakening the
security hardening in order to fix the regression, and I'm going to do
the same in Debian. This should stop msmtp from regressing in terms of
which features work, but I cannot guarantee that it does not make msmtp
exploitable. If I find a concrete attack, I will report it privately to
the security team.
If I understand, the problem is twofold:
1) you are worried that since msmtp wasn't written with setgid in mind,
there's a risk of someone elevating their privileges to $USER:msmtp to
execute code
=> Doesn't that just give you read access to /etc/msmtprc?
2) Glib should be hardened to treat setgid processes specially to make
it more secure. Doing so breaks the msmtp libsecret integration.
I would recommend removing the setgid support from msmtp, and recommending
that people who want a system-wide authenticating MTA whose credentials
are not disclosed to unprivileged users
Doing so by default would let everyone read creds from /etc/msmtprc
which sounds easier than abusing a setgid (even one not designed to run
that way).
should be using a fully-featured MTA that was designed to act as a
security boundary, like Exim or Postfix.
I don't fully understand your concerns but I trust you on their
seriousness. That said, msmtp is really nice due to not having to run a
daemon. I understand that makes it harder to secure the plain text creds
that are in its config file.
I've been using msmtp for years on hundreds of machine and never used
the libsecret integration. I'm sure I'm not alone so it would be nice to
not go back to having /etc/msmtprc world-readable for all of us.
As a user, I guess I wouldn't mind having that setgid behind a debconf
question. Would that middle ground work?
Regards,
Simon
