[exim-dev] [Bug 2000] BDAT injection/transmission character …

Inizio della pagina
Delete this message
Reply to this message
Autore: admin
Data:  
To: exim-dev
Oggetto: [exim-dev] [Bug 2000] BDAT injection/transmission character loss
https://bugs.exim.org/show_bug.cgi?id=2000

Andreas Metzler <eximusers@???> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---


--- Comment #5 from Andreas Metzler <eximusers@???> ---
(In reply to Jeremy Harris from comment #2)
> Not a bug: you have sent an invalid wire-format block for the message.


Hello,

on further testing I think there is bug in Exim's handling of these invalid
inputs as it causes invalid outgoing SMTP:

read_message_bdat_smtp() relies on input separated by \r\n. The \r-s are not
stored in the spoolfile but are counted, their number is saved as
body_linecount. The \n are stored in the spoolfile unchanged.

On sending out via BDAT exim sends a \r\n for every \n in the spoolfile and
calculates the chunksize as message size (including headers) + body_linecount.

By injecting messages via BDAT a submitter can arbitrarily set body_linecount
in the spoolfile. - Submit \n separated lines without any \r for
body_linecount=0, submit messages with a number of \r *not* followed by
corresponding \n for a body_linecount *greater* than the actual number of lines
in spoolfile.

[1] A too small body_linecount seems to be rather harmless, CHUNK size is too
small and the message is successfully transmitted but some characters are lost.
Also exim will send the part of the message that did not fit into the CHUNK
after BDAT ... LAST, causing
SMTP syntax error in [...] unrecognized command

[2] OTOH a too big body_linecount causes not only messages to be stuck on the
queue but also hanging exim delivery processes. The message content will not
fill the announced chunk size and the remote sits there waiting for exim to
finish the message transmission.

[1] seems to be in the grey zone between bug and just a little bit ugly. - Imho
I should not be able to inject messages which cause SMTP syntax error on
outgoing messages.

[2] is worse, there is a DOS aspect. (hanging delivery processes, perhaps
breaking retry configuration, too.)

cu Andreas

--
You are receiving this mail because:
You are on the CC list for the bug.