Two vulnerabilities in ssmtp were discovered, which allow compromising a vulnerable system, resulting in server crash or execution of arbitrary code. Rated by Secunia in their advisory as "highly critical", "system access from remote".
Reproducible: Didn't try
Steps to Reproduce:
The advisory Secunia issued today can be found here:
CVE reference: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0156
The vulnerabilities are caused by 2 format string errors in the functions die()
Secunia says, one should use a different product until the bugs have been fixed,
there seem to exist no workaround or patched version until now.
I just received the Debian advisory about this issue:
They seem to have fixed the problems in 126.96.36.199 (stable, woody), http://security.debian.org/pool/updates/main/s/ssmtp/ssmtp_188.8.131.52.tar.gz
The changelog says:
ssmtp (184.108.40.206) stable-security; urgency=high
* Non-maintainer upload by the Security Team
* Fix two format string vulnerabilities (die() and log_event())
discovered by Max Vozeler <email@example.com> (CAN-2004-0156)
-- Matt Zimmerman <firstname.lastname@example.org> Mon, 12 Apr 2004 09:21:54 -0700
The advisory states the update for 2.60.6 (debian unstable, sid) will come soon (I expect 220.127.116.11). The newest in portage is 2.60.4, the current stable on 2.48
Waiting for upstream 18.104.22.168.
Please note that exploit need that you forward mail to an untrusted server.
I can take this one if nobody else wants it.
2.60.7 is available upstream :
net-mail people, can we have a bump to this one ?
CondorDes: this one is all yours :)
Thanks in advance,
There was an email on Bugtraq today about an insecure file creation: http://www.securityfocus.com/archive/1/360626/2004-04-16/2004-04-22/0
Having reviewed the source, it looks like 2.60.7 is vulnerable to this. Should we wait to bump?
This is a fairly serious flaw.
email@example.com should not have to wait any longer.. If patches are ready
and firstname.lastname@example.org is taking to long (>=48 hrs) and a CAN-XXXX-XXX exists
then we should add the patches in without having to wait on them.
This really should be a P1/blocker, not a P2/major, since it has the potential of being a remote-root.
net-mail -- Please wake up. I don't want to step on your turf, but if I don't hear from you on this in 6 hours or so, we're going to start looking into pushing this one ourselves.
solar -- I think we're also waiting on a fix for bug 48435. However, someone should check to see if that actually affects us.
Bug 48435 does not affects us or seemly anybody for that matter. That
support is just flat out broke. I'll still put a patch together however
to fix it, probably default the LOGFILE to /dev/stdout unless one is
passed in the form of CFLAGS="-DLOGFILE_FILENAME=blah" when I bump this
In portage as ssmtp-2.60.7.ebuild please test.
KEYWORDS="~x86 ~ppc ~sparc ~alpha ~hppa ~mips ~amd64 ~ia64 ~ppc64 ~s390"
Stable on alpha.
Stable on ppc
Stable on sparc.
Draft GLSA submitted with temporary id c31342a3b17660a2a671ba94782fe1fe.
security@ -- reviews please? Thanks.
Marked stable on mips.
KEYWORDS="~x86 ppc sparc alpha ~hppa mips amd64 ~ia64 ~ppc64 ~s390"
Removing arch-maintainers and adding specific arches.
Remaining arch maintainers please test and mark stable so
we can get this one out the door. -thanks
Stable on x86.
Marked stable on s390
stable on alpha and ia64
stable on ppc64
This is ready for a GLSA. We have one drafted ... klieber and Koon reviewed it, but it got changed after klieber reviewed it, so one more person needs to look at it.
Stable on hppa thanks vapier.