This is just a cross-post from SA bugzilla, so you guys could integrate patch as soon as their bug gets into resolved state. Reproducible: Always Steps to Reproduce: 1. Start spamd 2. Connect to spamd's tcp port, issue "CHECK SPAMC/1.2\r\nContent-length: 2000\r\n\r\n" 3. Disconnect, and repeat from step 2 4. All spamd's will be in IO waiting state, queuing up, spoiling system load and wasting memory. If steps 2 and 3 are repeated agressivly, it might kill the machine. If --max-clients is defined, spamd will start to refuse new clients. Expected Results: Define and enforce timeout values on spamd.
Lazar thanks for the notification. However I'm not authorized to view it. So please post any relevant information here.
I accessed the discussion through : http://issues.apache.org/eyebrowse/ReadMsg?listName=dev@spamassassin.apache.org&msgNo=11335 There seem to be an unchecked patch for 2.x, final fix targeted for 3.0.1.
Any luck locating the actual patch? Even with an account in the spamassassin bugzie access to the bug is blocked, and the thread talks around it (unless I missed it)
Michael: no -- they closed the door to get time to issue 3.0.1 before it gets any publicity. Maybe you should contact them to try to get it... or we should just shut up and wait :)
According to the mail thread you posted they're under the impression we already have it ;) I guess I concur - based on the thread, I've done a scan for IO::Socket timeout calls and come back empty handed, but haven't had much time to look further. I'll keep poking (when I remember to) until we hear something concrete from the SA folks.
Hmmm... I thought a quick workaround went into 3.0.0 but it doesn't seem so. A patch is under construction, the initially suggested (and untested) one is this <http://bugzilla.spamassassin.org/attachment.cgi?id=2346&action=view> one (if you can access it). But in my eyes this isn't really a DoS-issue, my comment from that bug: | Marking as security related, targeting at 3.0.1 for now. | | Would be cool if it could be fixed for 3.0.0 but if the fix is too complex and | this is not a regression compared to 2.6x, we should stay with out current | release schedule. This thing might sound grave but it doesn't sound like you | can remotely exploit it and if you have direct access to the spamd port, there | are other ways to DoS it.
I agree on the "hardly DoS" analysis. Decreasing Severity.
bug 68841 - sa 3.0.1 just added
Lot of obscurity around this bug... I'm not sure 3.0.1 is fixed, and I'm not sure we can upgrade 3.x to stable just for this bug... So we can either drop this bug telling direct access to spamd means you can DoS it so you have to restrict access, or we can try to see through SA bug 3782 by contacting them.
Malte: Any word on whether 3.0.1 resolves SA Bug 3782?
According to http://wiki.apache.org/spamassassin/changes301 it isn't fixed. Could someone with access to the SA bug (reporter / Malte ?) confirm ?
I removed the seurity flag from the bug (which got marked as a dup in between anyway) so you can make up your own mind. My point is still that this is hardly a high risk security flaw (I can tell you at least two simpler ways to DoS a spamd server if you've got access to the port), at least has it been there since spamd was invented. This doesn't mean it's not a bug, a fix is still being worked on.
There is a patch upstream to work around the problem though I hardly think this is worth a security bug.
OK, we should not consider that a vulnerability, it's by design. We should put a warning somewhere that spamd should not be open on untrusted networks anyway. Switching this to Default Configs.
Perl/SA team : Could you please add a warning (where you think it belongs, either as a ebuild warning or on the configuration item listing the interfaces spamd binds on, if any) stating that spamd was not designed to listen to an untrusted network and is vulnerable to DoS and eternal doom if you do use it like this.
Perl please provide a fix for comment #15.
Notes added to conf and ebuilds.
Fixed together with 3.0.2 bump. Now we need stable markings on the 3.0.x series (about time anyway). mips, please mark ~mips if ok other arches, please test and mark stable (if stable) spamassassin-3.0.2 : Target KEYWORDS="x86 ppc sparc ~mips alpha hppa amd64 ia64 ppc64"
Small quiz before bumping 3.x to stable... does spamass-milter work with it already? Because last time i checked it didn't with SA 3.0+ Thanks.
*Please* do not mark anything before 3.0.2 as stable. FYI: A fix for the problem this bug is actually about will probably go into 3.0.3.
works pretty good! stable on ppc64.
stable on ppc
stable on amd64
I don't think this should be in stable, I just restarted updated from 3.0.0-r1 to 3.0.2... It chew up 2G of VM and brought my system to a an unusable load of ~30! This is on amd64...
hmm... looks like it's not related directly to spamassassin as going down to the old version is doing the same thing: Use of uninitialized value in numeric gt (>) at /usr/lib/perl5/5.8.6/x86_64-linux/DB_File.pm line 271. Deep recursion on subroutine "DB_File::AUTOLOAD" at /usr/lib/perl5/5.8.6/x86_64-linux/DB_File.pm line 234. x86 version works fine... I can't really look into this further now, but I will on the 26th if nobody else has.
Jeremy, what you describe is often a symptom of an updated bdb without a recompiled DB_File. Re-emerge DB_File and everything should be fine. I added a page in our Wiki, please update <http://wiki.apache.org/spamassassin/DeepRecursionInDbFile> if you can find out anything new.
Yep, that was it. Thanks Malte. Could we get this info added to the GLSA comments: -- It is recommended that you emerge spamassassin with FEATURES=maketest set. If you experience high load and errors about deep recursion in the DB_File module, cancel the emerge and first update the DB_File module by running: g-cpan.pl DB_File See http://wiki.apache.org/spamassassin/DeepRecursionInDbFile for more information -- Hopefully that will help anyone else that finds that problem when they upgrade.
Update line should probably read: emerge --ask --oneshot --verbose DB_File
ah... yes, use that instead... I didn't realize DB_File was actually in portage as a separate package as mine was provided by dev-lang/perl-5.8.6-r1... so yeah, use the emerge rather than g-cpan.pl ;) stable on x86
stable sparc
Stable on alpha.
Stable on hppa.
Thx everyone. ia64 and mips please remember to mark stable. Jeremy feel free to reopen if you think the DB_File thing should be noted in the ebuild.
