Package spampd
found 332259 2.20-16
found 332259 2.20-9
Tags +confirmed +upstream
Thanks
Sven Mueller wrote on 05/10/2005 22:25:
> Richard Wohlstadter wrote on 05/10/2005 16:56:
>
>>Package: spampd
>>Version: 2.20-9
>>
>>When processing an email with the following message id:
>>
>>Message-ID: <[EMAIL PROTECTED]>
>>
>>spampd would fail to process throwing the following error:
>>Oct 4 16:38:29 linuscs32 spampd[30364]: WARNING!! Error in
>>process_request eval block: Modification of a read-only value attempted
>>at /usr/lib/perl/5.8/Sys/Syslog.pm line 312, <_GEN_18> line 67
Reproducability:
I finally found the time to dig into the problem. Though I didn't find
out why the original fix of the problem by the upstream author
(replacing % with %% in Message-IDs) doesn't work in this case, I was
able to reproduce the problem with the message-ID stated above. Using
different message-IDs, all with %<something> in them, some reproduced
the problem while others didn't. I didn't find out why though. But it
probably only happens with %m in the message-ID.
Severity:
However, the symptom is that when the above error is issued, the
connection is taken down and the sending mailserver interprets this as
an intermediate problem, trying to resend the mail later (postfix for
example tries quite hard to resend it), which can lead to massive CPU
and network bandwidth consumption on the sending host (usually the front
smtp relay of the domain using spampd), which fulfills the criteria for
possible DoS attacks IMHO.
Fix:
Use the syslog call with "%s" as the first parameter after the level:
syslog(2, "%s" , ....)
instead of
syslog(2, ....)
The fix is small and easy, so I really would recommend a security
advisory about this.
The fix to the problem is attached to this mail, the fixed packages for
Debian sarge and sid can be downloaded from
https://mail.incase.de/spampd/sarge-security/ and
https://mail.incase.de/spampd/sid/ respectively.
Summary of the problem:
spampd can be made to close a connection when handling a mail with a
constructed message-ID, causing the sending mailserver (usually on the
same host) to retry delivery later. If a massive amount of such mails is
generated and injected into the mailserver which uses the effected
spampd instance, this can lead to a DoS on the mailserver.
Severity of the security problem:
Low. The attack which can be done with this problem is possible anyway.
However, the attack is made easier for the attacker (or more effective,
depending on the point of view taken).
Suggested action:
Update to fixed package (Version 2.20-9sarge2 or 2.20-17, both would
work on sarge and sid installations).
Regards,
Sven
#! /bin/sh /usr/share/dpatch/dpatch-run
## 60_fix_MSG_ID_DoS.dpatch by Sven Mueller <[EMAIL PROTECTED]>
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Fix DoS vulnerability in spampd (actually avoid vulnerability
## DP: in Sys::Syslog)
@DPATCH@
diff -urNad trunk/spampd /tmp/dpep.Ojo3au/trunk/spampd
--- trunk/spampd 2005-10-18 20:46:36.000000000 +0200
+++ /tmp/dpep.Ojo3au/trunk/spampd 2005-10-18 20:47:38.666084992 +0200
@@ -474,7 +474,6 @@
$msgid =~ s/^.*?<(.*?)>.*$/$1/; # keep only
the id itself
$msgid =~ s/[^\x21-\x7e]/?/g; # replace
all weird chars
$msgid =~ s/[<>]/?/g; # plus all
dangling angle brackets
- $msgid =~ s/%/%%/g; # escape % because
Sys::Syslog uses sprintf()
$msgid =~ s/^(.+)$/<$1>/; # re-bracket
the id (if not empty)
}
}
@@ -485,7 +484,7 @@
$recips ||= "(unknown)";
$sender ||= "(unknown)";
- $self->log(2, "processing message $msgid for ". $recips);
+ $self->log(2, "%s", "processing message $msgid for ". $recips);
eval {
