[exim-dev] [Bug 2250] New: Peculiarity with SMTP delivery in…

Startseite
Nachricht löschen
Nachricht beantworten
Autor: admin
Datum:  
To: exim-dev
Betreff: [exim-dev] [Bug 2250] New: Peculiarity with SMTP delivery in Exim 4.90.1
https://bugs.exim.org/show_bug.cgi?id=2250

            Bug ID: 2250
           Summary: Peculiarity with SMTP delivery in Exim 4.90.1
           Product: Exim
           Version: 4.90
          Hardware: x86
                OS: Linux
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Delivery in general
          Assignee: nigel@???
          Reporter: dpc22@???
                CC: exim-dev@???


We recently upgraded from Exim 4.89.1 to 4.90.1 because of the security
vulnerability which was announced here:

http://exim.org/static/doc/security/CVE-2018-6789.txt

No other changes in configuration. Operating system is RHEL 7.4

All seemed well until one my users reported that someone had been removed
from a Mailman mailing list because a series of bounces of the form:

  XXX@???
    host ppsw.cam.ac.uk [131.111.8.139]
    SMTP error from remote mail server after RCPT TO::
    501 NULL characters are not allowed in SMTP commands


ppsw.cam.ac.uk is our central mail hub, which receives messages from
lists.cam.ac.uk. A search through the logs at the receiving end uncovers
more specific information about what is going wrong:

2018-03-06 09:44:43 +0000 SMTP syntax error in "RCP? TO:<XXXXX@???>"
H=lists-4.csi.cam.ac.uk [131.111.8.103]:57345 I=[131.111.8.137]:25 NULL
character(s) present (shown as '?')

2018-03-06 12:12:54 +0000 SMTP syntax error in "RCPT TO:<XXXX?cam.ac.uk>"
H=lists-4.csi.cam.ac.uk [131.111.8.103]:34047 I=[131.111.8.137]:25 NULL
character(s) present (shown as '?')

2018-03-06 17:50:33 +0000 SMTP syntax error in "RCPT TO:<XXXX@?am.ac.uk>"
H=lists-4.csi.cam.ac.uk [131.111.8.103]:41460 I=[131.111.8.137]:25 NULL
character(s) present (shown as '?')

(I have replaced a few usernames of the form "dpc22" with "XXXX" to protect
the individual users privacy).

Note the "?" character appears at various different places in the SMTP
command, including the RCPT verb itself. This always seems to happen on a
token boundary rather than in the middle of word.

The sending end lists.cam.ac.uk is seeing around 30 to 60 "501 NULL
characters are not allowed in SMTP commands" errors each day out of several
hundred thousand delivery attempts.

This affects a number of different mailing lists that we run which have
several hundred users. The common feature would seem to be a long list of
"RCPT TO:" commands in a single SMTP dialogue.

Typically only a single user on a given list and if the problem repeats
then the same user is affected (which is the same offset into the list of
recipients recorded in the sending logs, so presumably the same offset into
the list of "RCPT TO:" commands for a particular mailing list).

When a specific user has repeated problems, it looks like the spurious NULL
character appears at the same location on the SMTP "RCPT TO:" command.

However the problem is intermittant: occasionally email gets through for
the user in question. One specific example from yesterday: one list
received four separate messages. Email failed for one specific user for two
of those messages, however that user received the other two messages.

I reverted from Exim 4.90.1 to a version of 4.89.1 with the single obvious
security fix from 4.90.1 applied:

    commit 062990cc1b2f9e5d82a413b53c8f0569075de700
    Author: Heiko Schlittermann (HS12-RIPE) <hs@???>
    Date:   Mon Feb 5 22:23:32 2018 +0100


        Fix base64d() buffer size (CVE-2018-6789)


        Credits for discovering this bug: Meh Chang <meh@???>


No other changes in configuration. The problem disappeared immediately, and
we haven't seen any recurrence in the last few hours.

Consequently I'm pretty sure that this is a problem with Exim 4.90.1, but
I'm struggling to think of a way to give you a reproducible test case.

Any ideas?

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