Secure testing team - Mar 2006 - Re: Bug#332259: spampd fails with ''Error in process_request'': Modification of read-only variable in Syslog.pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Fri, October 7, 2005 6:17, Martin Schulze said:
> Sven Mueller wrote:
>> I created a fixed package (actually two: one for sid/etch and one for
>> sarge), available at https://mail.incase.de/spampd/sarge-security/
>> respectively at https://mail.incase.de/spampd/sid/ (until my sponsor
>> finds the time to upload the latter to sid). Personally, I''m
indifferent
>> wether this fix should be uploaded to the testing-security archive,
>> since the fixed version should propagate quickly from sid.
>>
>> Security-Team: What else do I need to do to get the fixed version into
>> sarge/security?
>
> How does this represent a security bug?
>
> It''s not a denial of service unless spampd crashes and is
unavailable
> after misprocessing this mail.  According to the bug report, the daemon
> is reporting an error but continuing to work.
>
> Hence, it''s rather "one mail falls through" or
something.  Doesn''t sound
> security-relevant to me.
Well, it''s more of an indirect DoS. The mails are rejected with an SMTP
temporary failure code according to my quick test. This means that those
mails fill up the sending SMTP daemons queue (which is usually the same
host or a closely related host to the host spampd runs on).

In my opinion, this is a possible DoS attack. And since the fix (one might
call it workaround) is really minimal, I would really recommend updating
it in sarge.

Apart from that, this is bug is at least a serious problem, since it might
deny perfectly legal mails from reaching the envelope recipient.

Regarding the comment from Florian Weimer, wether this is really a spampd
bug or more a Net::Server bug, I must say that I didn''t (and
don''t) have
time to analyze it. But I think it would be more a Sys::Syslog bug.
However, I don''t know wether using a "%s" as first argument
would work as
expected (I would have to test it more intensively, and it certainly
isn''t
the minimal fix for the problem, just the right one in the long run).
However, even if it would be a Sys:Syslog or Net::Server bug, I would
still think it is right for spampd to work aroung that bug now (since the
Sys::Syslog/Net::Server fix would be more complex).

regards,
Sven

PS: It is really unlikely for me to be online much this week, so please
don''t expect timely answers before Tuesday 18th.

- --
Still in NM process

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDSVNvg3izVowCbSERAvrDAKD9FY3nSs31e5HQE/VLXJhELjg9AgCfeSd1
mctgw1PqDHJXi/Q0zpRyf/Y=a9ZH
-----END PGP SIGNATURE-----

On Thu, Oct 06, 2005 at 03:30:32PM +0200, Sven Mueller
wrote:
> Package spampd
> found 332259 2.20-16
> Tags 332259 +pending +upstream
> thanks
> 
> I created a fixed package (actually two: one for sid/etch and one for
> sarge), available at https://mail.incase.de/spampd/sarge-security/
> respectively at https://mail.incase.de/spampd/sid/ (until my sponsor
> finds the time to upload the latter to sid). Personally, I''m
indifferent
> wether this fix should be uploaded to the testing-security archive,
> since the fixed version should propagate quickly from sid.
> 
Hi there,

As part of testing-security, we''ll probably only upload this to the
archive if it becomes blocked from transitioning into testing of it''s
own accord. If this does happen, the patches are really useful, thanks
:)

Neil
-- 
   __   
 .?  `. neilm@debian.org | Application Manager
 : :'' ! ---------------- | Secure-Testing Team member
 `. `?  gpg: B345BDD3    | Webapps Team member
   `-   Please don''t cc, I''m subscribed to the list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20051006/8ec6f575/attachment.pgp

Martin Schulze schrieb:
> Sven Mueller wrote:
> 
>>>Hence, it''s rather "one mail falls through" or
something.  Doesn''t sound
>>>security-relevant to me.
>>
>>Well, it''s more of an indirect DoS. The mails are rejected with
an SMTP
>>temporary failure code according to my quick test. This means that those
>>mails fill up the sending SMTP daemons queue (which is usually the same
>>host or a closely related host to the host spampd runs on).
> 
> The mails should be automatically cleaned from the queue when they are
> locked in it for too long.
Sure, usually after several days. By that time, millions of mails could
have accumulated if the attacker wants that. For any kind of mail serice
provider, this would be a serious threat. And I don''t know any MTA
which
can cope easily with a huge number of stalled messages (read: many
thousand stalled messages).

Though I respect your sceptic view on this, I still think this is a
possible DoS on the mailserver which uses the spampd instance. Not an
extremely serious threat (since relatively few mailservers use spampd
and the attacker would need to know it is used, which is hard to
detect), but still a threat.
>>Apart from that, this is bug is at least a serious problem, since it
might
>>deny perfectly legal mails from reaching the envelope recipient.
> 
> Spam filters usually do that...
Not this one. spampd is usually only used to _mark_ spam, not to reject it.

regards,
Sven

PS: Though online again (yippie), I still can''t work on this problem
(not being able to log into any of my Linux boxes right now). I still
try to recover full network access. At the very latest, I should be able
to get to this problem some more when back in the office Tuesday next week.

Sven Mueller wrote:
> I created a fixed package (actually two: one for sid/etch and one for
> sarge), available at https://mail.incase.de/spampd/sarge-security/
> respectively at https://mail.incase.de/spampd/sid/ (until my sponsor
> finds the time to upload the latter to sid). Personally, I''m
indifferent
> wether this fix should be uploaded to the testing-security archive,
> since the fixed version should propagate quickly from sid.
> 
> Security-Team: What else do I need to do to get the fixed version into
> sarge/security?
How does this represent a security bug?

It''s not a denial of service unless spampd crashes and is unavailable
after misprocessing this mail.  According to the bug report, the daemon
is reporting an error but continuing to work.

Hence, it''s rather "one mail falls through" or something. 
Doesn''t sound
security-relevant to me.

Regards,

	Joey

-- 
Everybody talks about it, but nobody does anything about it!  -- Mark Twain

Please always Cc to me when replying to me on the lists.

Sven Mueller wrote:
> > Hence, it''s rather "one mail falls through" or
something.  Doesn''t sound
> > security-relevant to me.
> 
> Well, it''s more of an indirect DoS. The mails are rejected with an
SMTP
> temporary failure code according to my quick test. This means that those
> mails fill up the sending SMTP daemons queue (which is usually the same
> host or a closely related host to the host spampd runs on).
The mails should be automatically cleaned from the queue when they are
locked in it for too long.
> Apart from that, this is bug is at least a serious problem, since it might
> deny perfectly legal mails from reaching the envelope recipient.
Spam filters usually do that...

Regards,

	Joey

-- 
This is GNU/Linux Country.  On a quiet night, you can hear Windows reboot.

Package spampd
found 332259 2.20-16
Tags 332259 +pending +upstream
thanks

I created a fixed package (actually two: one for sid/etch and one for
sarge), available at https://mail.incase.de/spampd/sarge-security/
respectively at https://mail.incase.de/spampd/sid/ (until my sponsor
finds the time to upload the latter to sid). Personally, I''m
indifferent
wether this fix should be uploaded to the testing-security archive,
since the fixed version should propagate quickly from sid.

Martin: Would you please upload the sid version to the archive?

Security-Team: What else do I need to do to get the fixed version into
sarge/security?

regards,
Sven

PS: For various reasons, I probably won''t be online again until
Tuesday,
18th, so feel free to NMU if needed.
PPS: The fix is rather simple. Instead of the non-working escaping for %
(which got replaced by %% up until version 2.20-9), I chose to replace
it with the non-special character "?", like it is already done with
non-printable and high (>128) characters.
PPPS: The packages I uploaded to my server have been signed with the
same gpg-key as this mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 186 bytes
Desc: OpenPGP digital signature
Url :
http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20051006/edf1e936/signature.pgp