ssmtp.conf security

confirming the issue as critical

I'd like to mark this as a security issue but I don't see how that's possible (except by adding a CVE report). I'll just subscribe the Ubuntu security team for now to ask for their suggestion on how to proceed.

@Rolf
I have set this as a 'security vulnerability' in till a member of the security team can have a look at this.

@All
I have searched the CVE and there is no reference to this issue I could find. As this is a packaging issue I believe this is up to Ubuntu/Debian to fix.

Looking through the Debian bugs I think these two bugs would be of interest to the issue:
*http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=251462
*http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=181315

I do not run a Debian system so cannot confirm if this is an issue in there package.

I fixed this by doing the following:

chmod 2555 /usr/sbin/ssmtp
chgrp mail /usr/sbin/ssmtp
chmod 640 ssmtp/ssmtp.conf

This should be the default for this package. You don't want plaintest passwords visible for any mail account on the system. It's a simple fix!

here is my try to patch this issue by using the source-package. Would be nice to get feedback on the patch. I was using the suggestion from rick hart

Still present on natty

@Michael Basse
I applied what your patch does by hand and cannot send mail using sendmain as a non root user. I can only send email when ssmtp.conf is readable to all.

ps. If you use Google then opt-into "2-step verification" (https://www.google.com/accounts/b/0/SmsAuthConfig) where you can get application-specific passwords so your main password does not need to be in ssmtp.conf.

so the other solution would be, that ssmtp will run as the ssmtp-user instead of the real-user.

like /etc/ssmtp/ssmtp.conf can only be read from root/ssmtp-group as you initially suggested.

Reducing the priority as people putting their passwords in this file should check its permissions.

That said, it should certainly be fixed. This package is in universe and in Ubuntu we do not want to carry a delta with Debian, as we won't be able to automatically sync the package. Can someone interested in this bug forward it to Debian, add a reference to the Debian bug, and then mark this back to 'Triaged'. Thanks!

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to 'New'. Thanks again!

just because nobody forwarded this issue to the horrid Debian BTS does not make this an invalid problem. I'm saddened to see this hasn't been dealt with already.

This package is in universe and community supported. As I said before in comment #8, we won't carry a delta with Debian for this issue. If someone wants this fixed, please get it fixed upstream (Debian) and then Ubuntu will get it automatically. Since that hasn't happened, this bug hasn't been fixed yet. Marking "Won't Fix" for now (which is what it should've been in comment #10) since this bug is almost a year and a half old with no progress. If someone steps up to work on this in Debian, please reopen and mark as "Triaged" and we can incorporate the fix in Ubuntu. Thanks.

Someone opened bug #661954 in Debian in 2012 and I just provided a patch. If the Debian maintainer accepts it there is a chance for this to make it into Trusty.

The Debian maintainer never commented in the Debian bug so I think there is no other way than carrying an Ubuntu delta for this. The attached debdiff fixes the problem.

patch looks good to me. Please apply.

I strongly dislike adding a new setgid binary to the system, writing these requires care and diligence. Adding setgid after the fact is extremely dangerous.

Re-using an existing group is also dangerous; group mail for example has write access to /var/mail.

This might just be the limit of what this tool is prepared to handle; systems with untrusted users maybe should stick to exim or postfix or similar.

Thanks

This bug was fixed in the package ssmtp - 2.64-8ubuntu1

---------------
ssmtp (2.64-8ubuntu1) xenial; urgency=medium

  * Remove world read access to /etc/ssmtp/* and chgrp to "mail".
    Install the ssmtp binary as setgid and owned by "root:mail".
    LP: #654065, Closes: #661954

 -- Simon Deziel <email address hidden> Wed, 13 Apr 2016 15:44:14 +0000