Bugzilla – Bug 86764
VUL-0: CVE-2005-1266: spamassassin DoS
Last modified: 2021-11-08 14:05:01 UTC
Hi, this was sent to us via vendor-sec. To: vendor-sec@lst.de From: Josh Bressers <bressers@redhat.com> Subject: [vendor-sec] spamassassin DoS Errors-To: vendor-sec-admin@lst.de Date: Tue, 31 May 2005 17:25:07 -0400 [-- Anhang #1 --] [-- Typ: text/plain, Kodierung: 7bit, GröÃe: 0,3K --] Hello, I've been alerted by the spamassassin upstream regarding a DoS recently fixed. I'll attach the important bits below. The patch is for spamassassin 3.0.x. I believe the upstream fix is revision 168638 (svn diff -r 168637:168638 http://svn.apache.org/repos/asf/spamassassin) -- JB [-- Anhang #2: 803.1.txt --] [-- Typ: text/plain, Kodierung: 7bit, GröÃe: 1,8K --] On Sat, May 28, 2005 at 01:32:53PM -1000, Warren Togami wrote: > The private security issue in 4171, is vendorsec privy to that? > How severe is it? I don't mind letting you know what the ticket is about, it's just not available for the general public, so please keep it that way. Cc'ing the SA PMC so they know about this message. When SA parses a message, it needs to know when the headers end and the body begins. In the current 3.0 code, we assume that the header ends at either a blank line (normal) or when we see a MIME boundary. The problem is that we parse the Content-Type header so we can figure out what the boundary string is, and if SA receives an extremely long Content-Type header (especially one with tons of whitespace folding/continuation) that doesn't have a boundary in it (or it's at the end), parsing it over and over causes lots of wasted CPU time. In 3.1 (and with the patch for 3.0.4 I have up), we just stop parsing at something that doesn't look like a header. No more Content-Type parsing, so no more issue. The severity depends on what's in the header and your hardware. If I make a header with a "worst-case" Content-Type, my 2GHz Opteron goes from ~1s to 50s processing time. With the patch, the processing time goes back down to ~1s. The issue has only been reported once, and the message received looks to have accidentally been sent with the large header. FWIW. > Is a CVE CAN number already assigned with embargo date set? No. So far, this hasn't been considered major enough to report it anywhere. I would really like to get the patch in and a 3.0.4 released though. Just to get this out of the way. Arguably, it's the same type of issue as we had WRT the 2.64 release. -- Randomly Generated Tagline: Ideas are funny little things that don't work unless you try them out first. [-- Anhang #3: 3.0.x.patch --] [-- Typ: text/plain, Kodierung: 7bit, GröÃe: 20K --]
From: Josh Bressers <bressers@redhat.com> To: vendor-sec@lst.de Subject: Re: [vendor-sec] spamassassin DoS User-Agent: Mutt/1.4.1i Errors-To: vendor-sec-admin@lst.de Date: Tue, 31 May 2005 17:37:19 -0400 On Tue, May 31, 2005 at 05:25:07PM -0400, Josh Bressers wrote: > Hello, > > I've been alerted by the spamassassin upstream regarding a DoS recently > fixed. > > I'll attach the important bits below. The patch is for spamassassin 3.0.x. > I believe the upstream fix is revision 168638 (svn diff -r 168637:168638 > http://svn.apache.org/repos/asf/spamassassin) Please note that upstream wishes to treat this issue as embargoed and will make an announcement with the 3.0.4 release that is pending. They have not given me a date they expect to release 3.0.4. If I hear anything I'll forward it along. -- JB
Created attachment 38511 [details] 3.0.x.patch
Created attachment 38512 [details] sa-exploit.gz
Urgs... That means we have to update to 3.x now (especially on SLES9 and SLES8)? Or isn't version 2.64 vulnerable? What does the sentence "Arguably, it's the same type of issue as we had WRT the 2.64 release." mean? We had? There was a fix?
Choeger, can you test the attached exploit with SA please? I'll have a look at the source...
jup
time cat sa-exploit |spamassassin [...] real 1m15.540s user 1m5.191s sys 0m1.371s mit sa version 3.0.3
Hm, the code looks very different in 2.64. I wrote JB and asked about 2.64 and a patch. Let's see what he will tell us. :)
WRT comment #7: Is this too long? I don't think so. :)
Tested spamassassin-3.0.2-4 from SL9.3 on a machine with 1GB RAM and dual P4 1GHz. It eats up 99% CPU time and runs: real 2m25.085s user 2m20.395s sys 0m2.580s
thomas@gate:~> rpm -q spamassassin spamassassin-2.64-5 thomas@gate:~> cat /etc/SuSE-release SuSE Linux 8.1 (i386) VERSION = 8.1 real 0m20.083s user 0m11.320s sys 0m1.280s
Well, if somebody uses this "weakness" for a DoS attack, then it might be to long. And keep in mind, that it uses 100% CPU time per sa process per mail with such a header. On a SLES9 with the original (old) sa 2.64 version: real 0m7.035s user 0m0.872s sys 0m0.686s and using version 3.0.3 (same machine): real 1m0.555s user 0m51.867s sys 0m4.335s so it looks like 2.64 is not "vulnerable"...
Yes, after seeing the difference between 2.64 and 3.x I also recognized that it is too long. :) I agree that 2.64 looks unaffected.
JB refered to CAN-2004-0796 which we fixed in bug #58546
fine, then we have to update only 9.2 and 9.3
SM-Tracker-1460
Created attachment 38663 [details] patchinfo-box.sa i omitted package perl-spamassassin, please make sure that it was the right decission.
It is perl-spamassassin, that conains the involved code. I'll change the patchinfo.
CAN-2005-1266
From: Warren Togami <wtogami@redhat.com> User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) To: security@spamassassin.apache.org Cc: Josh Bressers <bressers@redhat.com>, Daniel Quinlan <quinlan@pathname.com>, vendor-sec@lst.de Subject: Re: [vendor-sec] Re: SpamAssassin notice for vendor-sec Errors-To: vendor-sec-admin@lst.de Date: Tue, 07 Jun 2005 21:10:22 -1000 WAIT!!!! Oh crap. Duncan (from Debian) pointed out to me a possible problem with the 3.0.4 release. Apparently Duncan and I had tested his test case on the earlier much more invasive patch, and did not test it again with the smaller, less invasive patch that went into 3.0.4. Athlon64 3200+ with 1GB RAM. time cat sa-exploit |spamassassin (Gets stuck for 2 minutes at 100% CPU usage.) real 2m2.075s user 1m55.468s sys 0m0.202s I guess the key questions are: 1) What was used to test 3.0.4? 2) Is Duncan's test case possible to send over SMTP? While discussing this with Duncan, my cable modem died and by the time I got back online he went to sleep. I myself need to sleep soon... Warren Togami wtogami@redhat.com _______________________________________________ Vendor Security mailing list
Hm, other folks are reporting that 3.0.4 works fine, so this issue should not block us.
Other software products have the same issue and it looks like the coordinated release date will change. To: vendor-sec@lst.de Cc: security@spamassassin.apache.org From: Daniel Quinlan <quinlan@pathname.com> Subject: [vendor-sec] follow-up on SpamAssassin issue Errors-To: vendor-sec-admin@lst.de Date: 08 Jun 2005 12:42:02 -0700 1. The issue is that long misformatted Content-Type headers can cause message parsing to take an extremely long time (minutes). Apache SpamAssassin 3.0.4 fixes the issue (in addition to including other bug fixes). 2. The issue also exists in Razor2 and perhaps other software. We are notifying the Razor2 developers. 3. Because other software is affected, we are asking for an extension of the embargo for an additional week (out to 2005-06-15 20:00 UTC). Specifically, we're asking that vendors to neither distribute the details of the exploit more widely nor ship 3.0.x plus the fix. Shipping 3.0.4 is fine with us, of course. 4. We recommend upgrading to 3.0.4, but if you must apply a single patch timed with the end of the embargo, here it is: http://tinyurl.com/ey7a4 Thanks. Daniel --
I would suggest to switch to the newest sa version (3.0.4) for 9.2 and 9.3 just for the usual reasons. AJ?
As aj is on vacation, Gerald, could you approve?
Yes, I guess this is fine. We need to make an update in any case, for the security issue, and if this makes your life quite a bit easier (and also provides users better protection), let's do the version update.
packages and patchinfo have been submitted
adv and packages released
CVE-2005-1266: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P)