Bug 86764 (CVE-2005-1266)

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)