https://bugs.exim.org/show_bug.cgi?id=2880
Bug ID: 2880
Summary: missing support for quoted newline when parsing Avast
response
Product: Exim
Version: 4.92
Hardware: x86-64
OS: Linux
Status: NEW
Severity: bug
Priority: medium
Component: Content Scanning
Assignee: tom@duncanthrax.net
Reporter: pcernko@mpi-klsb.mpg.de
CC: exim-dev@exim.org
Created attachment 1412
--> https://bugs.exim.org/attachment.cgi?id=1412&action=edit
correctly handle quoted newline chars in avast response before parsing line
Hi Exim-Devs,
I discovered, that the parser for Avast's responses for content scans does not
correctly handle quoted newlines.
We recently had two mails, which contained attachments where the "filename"
property contained newlines (encoded with '=?UTF-8?B?'). Avast's response
formated them as
220 DAEMON
SCAN /tmp/outlook-icon.eml
210 SCAN DATA
SCAN /tmp/outlook-icon.eml|>PartNo_0#2596942889 [+]1.0
SCAN /tmp/outlook-icon.eml|>PartNo_1#3294019999 [+]1.0
SCAN /tmp/outlook-icon.eml|>Outlook-Logo,\ icon.png#2773048428 [+]1.0
SCAN /tmp/outlook-icon.eml|>Outlook-Icon\
\
Desc.png#235873156 [+]1.0
SCAN /tmp/outlook-icon.eml|>Outlook-Icon\
\
Desc.png#235873156 [+]1.0
SCAN /tmp/outlook-icon.eml|>Outlook-Icon\
\
Desc.png#2052662841 [+]1.0
SCAN /tmp/outlook-icon.eml|>Outlook-Icon\
\
Desc.png#3808441235 [+]1.0
SCAN /tmp/outlook-icon.eml [+]0.0
200 SCAN OK
which seems to be correct according to the protocol specification according to
your comment in malware.c. However, the parser tries to parse this answer
line-by-line and obviously fails to do so as some lines are missing the
trailing "tab [ ] marker" format. Instead the unparsable line is written to
panic log and the message is deferred. As the sending server retries the panic
log is filled slowly with these lines but the mail won't get handled as
expected (accept or reject).
I attached a patch, that tries to handle this issue by reading more lines until
the line does not end with the quoting '\' char any more. Then the
concatenation of all read lines is used for parsing against the different
regexps.
The patch was developed and tested for exim-4.92 but it seems to (at least)
apply for the current version too. I would appreciate if you could integrate
this patch (or it's idea) in the next release. Feel free to adopt the code if
it does not suite your quality standards, coding style or anything else.
Regards!
--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Bug ID: 2880
Summary: missing support for quoted newline when parsing Avast
response
Product: Exim
Version: 4.92
Hardware: x86-64
OS: Linux
Status: NEW
Severity: bug
Priority: medium
Component: Content Scanning
Assignee: tom@duncanthrax.net
Reporter: pcernko@mpi-klsb.mpg.de
CC: exim-dev@exim.org
Created attachment 1412
--> https://bugs.exim.org/attachment.cgi?id=1412&action=edit
correctly handle quoted newline chars in avast response before parsing line
Hi Exim-Devs,
I discovered, that the parser for Avast's responses for content scans does not
correctly handle quoted newlines.
We recently had two mails, which contained attachments where the "filename"
property contained newlines (encoded with '=?UTF-8?B?'). Avast's response
formated them as
220 DAEMON
SCAN /tmp/outlook-icon.eml
210 SCAN DATA
SCAN /tmp/outlook-icon.eml|>PartNo_0#2596942889 [+]1.0
SCAN /tmp/outlook-icon.eml|>PartNo_1#3294019999 [+]1.0
SCAN /tmp/outlook-icon.eml|>Outlook-Logo,\ icon.png#2773048428 [+]1.0
SCAN /tmp/outlook-icon.eml|>Outlook-Icon\
\
Desc.png#235873156 [+]1.0
SCAN /tmp/outlook-icon.eml|>Outlook-Icon\
\
Desc.png#235873156 [+]1.0
SCAN /tmp/outlook-icon.eml|>Outlook-Icon\
\
Desc.png#2052662841 [+]1.0
SCAN /tmp/outlook-icon.eml|>Outlook-Icon\
\
Desc.png#3808441235 [+]1.0
SCAN /tmp/outlook-icon.eml [+]0.0
200 SCAN OK
which seems to be correct according to the protocol specification according to
your comment in malware.c. However, the parser tries to parse this answer
line-by-line and obviously fails to do so as some lines are missing the
trailing "tab [ ] marker" format. Instead the unparsable line is written to
panic log and the message is deferred. As the sending server retries the panic
log is filled slowly with these lines but the mail won't get handled as
expected (accept or reject).
I attached a patch, that tries to handle this issue by reading more lines until
the line does not end with the quoting '\' char any more. Then the
concatenation of all read lines is used for parsing against the different
regexps.
The patch was developed and tested for exim-4.92 but it seems to (at least)
apply for the current version too. I would appreciate if you could integrate
this patch (or it's idea) in the next release. Feel free to adopt the code if
it does not suite your quality standards, coding style or anything else.
Regards!
--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##