link to git repo: http://git.dbmail.eu/paul/dbmail/log/?h=dbmail_3_2&id=v3.2.2 The bug seems to be around for the 3.2 series only (so current stable is fine - but old). http://blog.gmane.org/gmane.mail.imap.dbmail/day=20141219 <- mailinglist post of author about the vulnerability a copy of the relevant mail here in case: =========================================== Paul J Stevens | 19 Dec 22:55 2014 Security alert: disable CRAM-MD5 if you don't use it Hi all, It was brought to my attention that dbmail currently authenticates any user with any password if the client issues an CRAM-MD5 authentication exchange, while the user - which does need to exist - has it's password stored in an encrypted format. This affects all versions supporting cram-md5, so 3.0.0 and later. Installations using authldap are *not* affected. You should disable CRAM-MD5 in dbmail.conf if you store password encrypted. A patch was already pushed to git both on dbmail.eu and github. I'll release a patched version asap. =========================================== Couldn'T get a hold of someone from security on IRC earlier so reporting a Bug. In case of an unstable version being the only affected one what would be the best course of action? - I intend to package.mask 3.2.0 later when I am on my dev box again (I never added 3.2.1) and also I'D like to stable-req 3.1.17, since I just added 3.2.2 -- or would this warrant going for a faster STABLE-REQ of current 3.2.2 with the security fix? Please let me know what would be the preferred course of action from your point of view.
forgot to add this: http://article.gmane.org/gmane.mail.imap.dbmail/16716 From: Paul J Stevens <paul <at> nfg.nl> Subject: Re: Security alert: disable CRAM-MD5 if you don't use it Newsgroups: gmane.mail.imap.dbmail Date: 2014-12-20 22:20:13 GMT (1 week, 2 days, 18 hours and 13 minutes ago) Ok. Good news: dbmail-3.1 is not affected. Apparently the problem only occurs in 3.2.0 and 3.2.1. It's definitely a regression. Bad news: if you use 3.2, you should apply the patch I pushed yesterday. The workaround offers no real protection, as Caspar correctly surmised. On 20-12-14 15:10, Casper Langemeijer wrote: > I imagined the capability string only was the advertised capabilities, > so I checked the source. Nowhere in the dbmail source I see that > CRAM-MD5 is actually disabled, but I could be missing the location. > Could dbmail still authenticate a malicious client? > _______________________________________________ > DBmail mailing list > DBmail <at> dbmail.org > http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail > -- ________________________________________________________________ Paul J Stevens pjstevns <at> gmail, twitter, github, linkedin www.nfg.nl/info <at> nfg.nl/+31.85.877.99.97
Thanks for the report. Let us know if we can stabilize the newer version.
I've been running this version on my server since yesterday and (except something that was my mistake afaik) no problems so far. I suppose we could start stabilizing progress - or do you want to wait another day or two first since it's been just about 24h that i've been running this version on my server)
@agp & rest of security team: I am still running this version without any problems so since it works for me and it is a security issue I'd consider it ready for STABLEREQ
forgot to add STABLEREQ keyword and to CC arches .. done now.
amd64 stable
x86 stable. Maintainer(s), please cleanup. Security, please vote.
ago, since i couldn'T reach you on irc just now.. what do you mean cleanup? -- do you mean the 2 other bugs about 3.2.0 ?
Cleanup means removing the vulnerable version(s), in this case 3.2.0 from the tree. This can either be done by dropping it altogether or package.mask that ebuild (as you mentioned in #c0) GLSA vote: no.
GLSA vote: no.
ok i will just remove it then, since I see no reason to keep it around.
am I supposed to remove the cleanup tag or is security going to do that ?
(In reply to Thomas Raschbacher from comment #12) > am I supposed to remove the cleanup tag or is security going to do that ? Thomas, usually if you are done cleanup it is all the way at the end, so at that point maintainers just paste the their cvs checkin/changelog message. Yours being: 04 Jan 2015; Thomas Raschbacher <lordvan@gentoo.org> -dbmail-3.1.15.ebuild, 6 -dbmail-3.2.0.ebuild: 7 removed vulnerable 3.2.0 (bug #534020) and old ~arch 3.1.15 This is only in the case of closing the bug since security should close security bugs. For anything else in the bug (stabilization for stable packages, etc just feel free to make the changes).
