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 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. 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 should be using a fully-featured MTA that was designed to act as a security boundary, like Exim or Postfix. msmtp's design is fine for simpler use-cases where the process sending email is allowed to have enough privileges to know the password, but it does not seem to be designed to be used as a security boundary, which means it is dangerous for Debian-specific changes to make it into a security boundary. Thanks, smcv
