Several issues fixed in spamassassin-3.4.2: https://marc.info/?l=oss-security&m=153711731528265&w=2 https://lists.apache.org/thread.html/1ac11532235b5459aa16c4e9d636bf4aa0b141d347d1361e40cc1b78@%3Cannounce.apache.org%3E DoS in ~all SA installs: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-15705 Removed "." from @INC (cleanup/qa; exploitability unknown): https://cve.mitre.org/cgi-bin/cvename.cgi?name=2016-1238 RCE in PDFInfo plugin: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-11780 Local user code injection (config-specific?): https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-11781
FWIW just bumping the latest 3.4.1 ebuild to 3.4.2 and emptying out PATCHES= seems to work fine. Every one of those patches appears to be folded into upstream 3.4.2, with the exception of the last hunks of spamassassin-3.4.1-bug_7361.patch: --- a/spamc/libspamc.c 2017-10-20 13:33:54.129653171 +1100 +++ b/spamc/libspamc.c 2017-10-20 13:36:09.429653849 +1100 @@ -1212,10 +1212,21 @@ if (flags & SPAMC_USE_SSL) { #ifdef SPAMC_SSL +#if OPENSSL_API_COMPAT >= 0x10100000L + OPENSSL_init_ssl(0, NULL); + meth = TLS_method(); + ctx = SSL_CTX_new(meth); + if (flags & SPAMC_TLSV1) { + SSL_CTX_set_min_proto_version(ctx, TLS1_VERSION); + } else { + SSL_CTX_set_min_proto_version(ctx, SSL3_VERSION); + } +#else SSLeay_add_ssl_algorithms(); meth = SSLv23_client_method(); SSL_load_error_strings(); ctx = SSL_CTX_new(meth); +#endif #else UNUSED_VARIABLE(ssl); UNUSED_VARIABLE(meth); @@ -1599,10 +1610,17 @@ if (flags & SPAMC_USE_SSL) { #ifdef SPAMC_SSL +#if OPENSSL_API_COMPAT >= 0x10100000L + OPENSSL_init_ssl(0, NULL); + meth = TLS_method(); + ctx = SSL_CTX_new(meth); + SSL_CTX_set_min_proto_version(ctx, SSL3_VERSION); +#else SSLeay_add_ssl_algorithms(); meth = SSLv23_client_method(); SSL_load_error_strings(); ctx = SSL_CTX_new(meth); +#endif #else UNUSED_VARIABLE(ssl); UNUSED_VARIABLE(meth); I cannot find a hunk like that in the upstream bug referenced (https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7361). Perhaps it was removed since. I do not have an openssl-1.1.x system on which to test to see if that is in fact needed, but upstream seems to think it is not.
I wouldn't swear to it, but all of the patches that we use should be upstreamed. I'll commit the v3.4.2 with an empty PATCHES (after double-checking that they all fail to apply on v3.4.2) and we can see what happens.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0dbbc52674fccc8c21209fe42b9e66790369901f commit 0dbbc52674fccc8c21209fe42b9e66790369901f Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2018-09-18 02:05:09 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2018-09-18 02:43:25 +0000 mail-filter/spamassassin: new version 3.4.2. This new version incorporates a ton of fixes that have piled on top of v3.4.1 over the past few years. As a result, we are able to drop all of our PATCHES in the new ebuild. The new version also addresses four security vulnerabilities: * CVE-2016-1238 * CVE-2017-15705 * CVE-2018-11780 * CVE-2018-11781 Sadly, there is a new failure in the test suite (upstream bug 7622) so I've added RESTRICT=test for now. Stabilization of this version should already be fast-tracked for the security issues mentioned above, but just in case, the release notes have the following to say: If you do not update to 3.4.2, you will be stuck at the last ruleset with SHA-1 signatures in the near future. Bug: https://bugs.gentoo.org/666348 Bug: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7622 Package-Manager: Portage-2.3.40, Repoman-2.3.9 mail-filter/spamassassin/Manifest | 1 + mail-filter/spamassassin/spamassassin-3.4.2.ebuild | 242 +++++++++++++++++++++ 2 files changed, 243 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=27b0dc92ffcd4001fcc8489be7cd48029f259c3d commit 27b0dc92ffcd4001fcc8489be7cd48029f259c3d Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2018-09-18 18:28:21 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2018-09-18 18:38:12 +0000 mail-filter/spamassassin: disable a network test and drop RESTRICT=test. I originally added RESTRICT=test to spamassassin-3.4.2.ebuild because a test was failing, I didn't know why, and we needed to get the new version out to address multiple CVEs. It turns out that the one failing test is not respecting the fact that network access should be disabled in the test suite (upstream bug 7622). In the new revision, we kill that one test in src_prepare(). The rest of the tests should pass, so RESTRICT=test has been removed. Bug: https://bugs.gentoo.org/666348 Bug: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7622 Package-Manager: Portage-2.3.40, Repoman-2.3.9 .../{spamassassin-3.4.2.ebuild => spamassassin-3.4.2-r1.ebuild} | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
Updated to 3.4.2-r1 in production, seems to work fine, thanks @mjo.
I also updated yesterday and ran it overnight on our main MX. There is some annoying log spam, e.g. Sep 19 10:17:46 mx1 amavis[9235]: (09235-17) SA info: dns: new_dns_packet: domain is utf8 flagged: ns4.dnsmadeeasy.com but that's harmless and everything else is working as expected. It's not ideal that this security release also contains three years of bugfixes and new features, but hey: if the CVEs made them get 3.4.2 out the door, I'll take it =) Unless the other maintainers object, I'd be OK with stabilizing this ASAP, not just for the security issues but because sa-update is going to stop working in older versions after a few months. Even if there are new bugs in 3.4.2, we don't have much of a choice but to encounter & fix them.
Agreed, let's wait a few days and start stabilization :)
I added a patch a few days ago to kill that log spam. I don't see any other major problems, so I think we can stabilize it now.
amd64 stable
Should bug #666576 keep this from being stabilized?
x86 stable
(In reply to Philippe Chaintreuil from comment #10) > Should bug #666576 keep this from being stabilized? AFAIK upstream is still planning to break updates for 3.4.1, so we don't have much of a choice, but... I think bug #666576 comes down to "it sucks that they piled two years of feature updates into a point release, but they did." Even when that gets addressed upstream, the fix will probably only be a note in the changelog that says "upgrade your database." Users will still need to realize that 3.4.1 -> 3.4.2 is a major upgrade and that will probably only happen when they try to run it and notice that their databases need upgrading. We could add an elog that displays after the fact, I guess, but by then it doesn't really do you much good.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d1f932bc99ca56b177f4cdbc9e794c4914f80682 commit d1f932bc99ca56b177f4cdbc9e794c4914f80682 Author: Tobias Klausmann <klausman@gentoo.org> AuthorDate: 2018-10-18 11:44:01 +0000 Commit: Tobias Klausmann <klausman@gentoo.org> CommitDate: 2018-10-18 11:44:01 +0000 mail-filter/spamassassin-3.4.2-r2: alpha stable Bug: http://bugs.gentoo.org/666348 Signed-off-by: Tobias Klausmann <klausman@gentoo.org> mail-filter/spamassassin/spamassassin-3.4.2-r2.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Stable on alpha.
I'd be fine with just adding an elog. Patching their aws .sql files would be nice as well, but users who are upgrading are basically going to have to run an ALTER command anyway (or drop the table and re-add, losing all their data). The MySQL command is: ALTER TABLE awl ADD last_hit timestamp NOT NULL default CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP; I don't have a PgSQL install around to test, but my stab at it's would be: ALTER TABLE awl ADD COLUMN last_hit timestamp NOT NULL default CURRENT_TIMESTAMP;
Also you can use pkg_pretend to have it printed early (with a chance to abort the merge).
ia64 stable
ppc stable
sparc stable
hppa stable
arm stable
Looking good on ppc64. # cat spamassassin-666348.report USE tests started on Sa 8. Dez 20:59:02 CET 2018 FEATURES=' test' USE='' succeeded for =mail-filter/spamassassin-3.4.2-r2 USE='-berkdb -cron -ipv6 -ldap libressl -mysql -postgres -qmail -sqlite -ssl' succeeded for =mail-filter/spamassassin-3.4.2-r2 USE='berkdb -cron -ipv6 -ldap libressl -mysql postgres -qmail -sqlite -ssl' succeeded for =mail-filter/spamassassin-3.4.2-r2 USE='-berkdb -cron -ipv6 -ldap -libressl -mysql postgres -qmail sqlite -ssl' succeeded for =mail-filter/spamassassin-3.4.2-r2 USE='-berkdb -cron ipv6 -ldap -libressl mysql -postgres qmail sqlite -ssl' succeeded for =mail-filter/spamassassin-3.4.2-r2 USE='berkdb cron -ipv6 -ldap libressl -mysql postgres qmail sqlite -ssl' succeeded for =mail-filter/spamassassin-3.4.2-r2 USE='-berkdb -cron ipv6 ldap -libressl -mysql -postgres -qmail -sqlite ssl' succeeded for =mail-filter/spamassassin-3.4.2-r2 USE='-berkdb cron ipv6 -ldap -libressl -mysql -postgres qmail -sqlite ssl' succeeded for =mail-filter/spamassassin-3.4.2-r2 USE='berkdb cron ipv6 ldap -libressl -mysql -postgres qmail -sqlite ssl' succeeded for =mail-filter/spamassassin-3.4.2-r2 USE='berkdb cron -ipv6 -ldap libressl -mysql -postgres qmail -sqlite ssl' : blocked packages (probably) for =mail-filter/spamassassin-3.4.2-r2 USE='berkdb -cron ipv6 -ldap libressl -mysql -postgres qmail -sqlite ssl' : blocked packages (probably) for =mail-filter/spamassassin-3.4.2-r2 USE='-berkdb -cron ipv6 -ldap libressl mysql -postgres -qmail sqlite ssl' : blocked packages (probably) for =mail-filter/spamassassin-3.4.2-r2 USE='berkdb -cron -ipv6 -ldap -libressl -mysql -postgres qmail sqlite ssl' succeeded for =mail-filter/spamassassin-3.4.2-r2 revdep tests started on So 9. Dez 13:40:07 CET 2018 FEATURES=' test' USE='spamassassin' succeeded for net-mail/vpopmail FEATURES=' test' USE='spamassassin' succeeded for mail-filter/amavisd-new
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dc7e9cb73adc438aa7fc4c7b8ea090f9d9cdcd14 commit dc7e9cb73adc438aa7fc4c7b8ea090f9d9cdcd14 Author: Mikle Kolyada <zlogene@gentoo.org> AuthorDate: 2018-12-11 10:19:10 +0000 Commit: Mikle Kolyada <zlogene@gentoo.org> CommitDate: 2018-12-11 10:19:30 +0000 mail-filter/spamassassin: Security cleanup Bug: https://bugs.gentoo.org/666348 Signed-off-by: Mikle Kolyada <zlogene@gentoo.org> Package-Manager: Portage-2.3.51, Repoman-2.3.11 mail-filter/spamassassin/Manifest | 1 - .../files/spamassassin-3.4.1-bug_7199.patch | 280 ------------ .../files/spamassassin-3.4.1-bug_7208.patch | 31 -- .../files/spamassassin-3.4.1-bug_7223.patch | 14 - .../files/spamassassin-3.4.1-bug_7231-extra.patch | 140 ------ .../files/spamassassin-3.4.1-bug_7231.patch | 29 -- .../files/spamassassin-3.4.1-bug_7265.patch | 88 ---- .../files/spamassassin-3.4.1-bug_7361.patch | 491 --------------------- .../files/spamassassin-3.4.1-bug_7404.patch | 23 - .../files/spamassassin-3.4.1-bug_7462.patch | 198 --------- .../files/spamassassin-3.4.1-perl526.patch | 14 - .../spamassassin/spamassassin-3.4.1-r19.ebuild | 251 ----------- .../spamassassin/spamassassin-3.4.1-r20.ebuild | 251 ----------- .../spamassassin/spamassassin-3.4.1-r21.ebuild | 252 ----------- 14 files changed, 2063 deletions(-)
GLSA filed.
This issue was resolved and addressed in GLSA 201812-07 at https://security.gentoo.org/glsa/201812-07 by GLSA coordinator Aaron Bauman (b-man).
