Bug 43279 (CVE-2003-0540) - VUL-0: CVE-2003-0540: postfix remote DoS
Summary: VUL-0: CVE-2003-0540: postfix remote DoS
Status: VERIFIED FIXED
Alias: CVE-2003-0540
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: All Linux
: P3 - Medium : Normal
Target Milestone: ---
Assignee: Carsten Hoeger
QA Contact: Security Team bot
URL:
Whiteboard: CVE-2003-0540: CVSS v2 Base Score: 5....
Keywords:
Depends on:
Blocks:
 
Reported: 2003-07-28 17:30 UTC by Sebastian Krahmer
Modified: 2021-09-30 15:04 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
postfix patchinfo (527 bytes, application/octet-stream)
2003-07-28 18:42 UTC, Sebastian Krahmer
Details
postfix putonftp (416 bytes, text/blah)
2003-07-28 18:43 UTC, Sebastian Krahmer
Details
postfix putonftp (399 bytes, application/octet-stream)
2003-07-28 18:48 UTC, Sebastian Krahmer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Krahmer 2003-07-28 17:30:46 UTC
Mail from vendor-sec:

Date: Sun, 27 Jul 2003 23:46:16 +0200 (CEST)
From: Michal Zalewski <lcamtuf@coredump.cx>
Subject: Postfix up to 1.1.12 remote DoS


There is a remotely exploitable vulnerability in Postfix 1.1.11 and 1.1.12
(although earlier versions might be also vulnerable). The vulnerability
does not affect the most current version, 2.0, but 1.1.12, having no
publicly disclosed security problems, is still more than common, among
others being shipped in several popular Linux distributions, including Red
Hat 9.0.

The problem, which has been found during a routine testing of the daemon
shipped with Red Hat Linux, has been fixed silently, likely under the
following changelog entry: "Cleanup: more work on the trivial-rewrite
address rewriting and address resolving code".

The vulnerability lies in the address parser - which, on a side note, I
believe is the most fragile part of this application. By providing the
remote SMTP listener with a malformed envelope address, it is possible to,
depending on the method, either:

  - Cause the queue manager, nqmgr, to lock up permanently, effectively
    stopping any queue processing - all mail traffic supressed. Restarting
    the service has no effect - a specific entry has to be removed from
    the queue to fix the problem. For that reason, a builtin watchdog
    that restarts nqmgr after a period of nonresponsive behavior, is
    not able to cause a recovery from this condition.

    This is achieved by forcing the service to queue a mail to an address
    that would generate a bounce - depending on the configuration, it
    can be <nonexistent@local-server-name>, or, if user names are being
    checked, <nonexistent@[127.0.0.1]>. The "mail from" or "Errors-To"
    address should be set to "<.!>" or "<.!@local-server-name>".
...or...

  - Lock up this instance of the smtp listener in a unusable state
    that persists after the client disconnects. By repeating this,
    it is possible to DoS the service (or entire system, depending
    on the configuration) in a very effective manner.

    This can be achieved by providing any valid "MAIL FROM" in a SMTP
    conversation, and then supplying a "RCPT TO" similar to "MAIL FROM"
    in the previous example. If the server is vulnerable, the session
    should freeze at this point.

The latter approach, since it only creates a single stalled process,
is a less intrusive method of testing your systems for this issue.

The attack can be detected by looking for "resolve_clnt_query: null
recipient" in your maillog. DoSed queue manager and smtp listener
processes generate this message in a loop. The solution is to upgrade to
Postfix 2.0 patchlevel 13, available from http://www.postfix.org.

Several attempts to contact the author, Wietse Venema, have failed, with
all his publicly used addresses bouncing with "Service temporarily
unavailable" SMTP error from spike.porcupine.org.
Comment 1 Sebastian Krahmer 2003-07-28 17:30:46 UTC
<!-- SBZ_reproduce  -->
Are we affected at all? We have postfix 2.x?
Comment 2 Carsten Hoeger 2003-07-28 18:04:35 UTC
We are effected up to SuSE Linux 8.1 (including UL and SLES8)... :-((((
Comment 3 Carsten Hoeger 2003-07-28 18:08:08 UTC
I just tried to DoS a SLOX with success:

Just do:

telnet mailhost smtp
ehlo hostname
mail from: <.!>
rcpt to: <nonexistent@addre.ss>

after this part, no more mail is accepted anymore... :-(

The message to detect that is different to that of the report:

warning: resolve_clnt_query: bad read: Success
Comment 4 Sebastian Krahmer 2003-07-28 18:11:47 UTC
We do not have a patch yet. I asked vendor-sec list.
Should I send a laufzettel nevertheless?
What do you need at all?
Comment 5 Carsten Hoeger 2003-07-28 18:19:13 UTC
It looks like mail relays (like cantor) are not effected.
At least I was not able to reproduce the problem (thank god...).

I'll try to find a fix myself in the meantime. Please tell me ASAP, if you get a
fix from vendor-sec.

I need the usual program: putonftp, patchinfo and laufzettel...
Comment 6 Carsten Hoeger 2003-07-28 18:28:56 UTC
It looks like it definetely is VERY dependent on the configuration in use.
It looks like the author of the above report is overstating the situation.

1. He talks of nqmgr, which isn't used by default, because Wietse still does not
 trust it enough.
2. A postfix restart always results to a working system in my test cases, even
if I use nqmgr.
3. Certain setups are NOT effected at all (see cantor)
Comment 7 Carsten Hoeger 2003-07-28 18:36:49 UTC
Okay, now that I have the additional info, that there'll be a patch from Wietse,
and that we have an additional problem, I'll wait for this one...
Comment 8 Sebastian Krahmer 2003-07-28 18:42:25 UTC
Created attachment 13232 [details]
postfix patchinfo

please add more to the description field if necessary
Comment 9 Sebastian Krahmer 2003-07-28 18:43:13 UTC
Created attachment 13233 [details]
postfix putonftp
Comment 10 Sebastian Krahmer 2003-07-28 18:48:17 UTC
Created attachment 13234 [details]
postfix putonftp

Old putonftp had a bug :)
Comment 11 Sebastian Krahmer 2003-07-28 19:33:25 UTC
From vendor-sec:

CAN-2003-0468 Bounce scanning issue fixed in Postfix 1.1-12

        Postfix versions before 1.1.12 would allow an attacker to bounce-scan
        private networks or use the daemon as a DDoS tool by forcing the daemon to
        connect to an arbitrary service at an arbitrary IP address and receiving 
        either a bounce message or by timing.

        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0468

        The Common Vulnerabilities and Exposures project (cve.mitre.org) has
        assigned the name CAN-2003-0468 to this issue.
AN-2003-0540 Remote DoS

        Postfix versions 1.1.12 and previous have a bug where a malformed 
        envelope address can 1) cause the queue manager to lock up until a 
        entry is removed from the queue and 2) lock up the smtp listener 
        leading to a DoS

        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0540

        The Common Vulnerabilities and Exposures project (cve.mitre.org) has
        assigned the name CAN-2003-0540 to this issue.
Comment 12 Sebastian Krahmer 2003-07-29 16:52:21 UTC
Subject: Re: [lcamtuf@coredump.cx: Postfix up to 1.1.12 remote DoS (fwd)] (fwd)
To: Michal Zalewski <lcamtuf@coredump.cx>
Date: Mon, 28 Jul 2003 13:50:49 -0400 (EDT)
Cc: Wietse Venema <wietse@porcupine.org>
Message-Id: <20030728175049.D4A9BBC076@spike.porcupine.org>
From: wietse@porcupine.org (Wietse Venema)

Attached is a very simple bugfix for Postfix 1.1.12. I'd appreciate
it if you could take a look. Unfortunately, I found no workarounds
for sites that can't patch. Access restrictions on mail addresses
are applied AFTER the address is resolved to standard form, and as
we know that is too late. Turning off allow_percent_hack and
swap_bangpath is not sufficient, because @.@local.tld still breaks
Postfix in 1.1.* (but not earlier versions).

The problem does not exist in MY OWN default configurations of
Postfix 1.0.8 (a.k.a. postfix-20010228-pl08, released November 15,
2001) and postfix-19991231-pl13.  To break Postfix one would have
to turn off append_dot_mydomain, and use a slight variation of your
exploit. Some package maintainers may or may not have changed this
default. The same patch can be used here if desired.

I haven't looked at earlier Postfix versions.

I also haven't looked at other people's Postfix versions.

How do we go from here? I am ready to package up Postfix 1.1.13
and send a note to the Postfix mailing lists that 1.1.13 fixes a
problem with malformed addresses, with credits where it is due but
no exploit information.  That will give package maintainers time
to roll out their own versions.  I see little benefit in releasing
patched Postfix versions for versions from two years ago; people
can use the same patch as for 1.1.12.

To summarize my understanding, the exploit with the envelope
recipient address affects smtpd, and requires that one has relay
access permission.  The exploit with the Errors-To: or MAIL FROM
address affects qmgr, and requires that mail is accepted then
bounced. With Postfix < 2.0, any non-existent local address will
do.

        Wietse
diff -cr /tmp/postfix-1.1.12/src/trivial-rewrite/resolve.c
src/trivial-rewrite/resolve.c
*** /tmp/postfix-1.1.12/src/trivial-rewrite/resolve.c   Fri Nov 22 12:32:33 2002
--- src/trivial-rewrite/resolve.c       Mon Jul 28 11:36:49 2003
***************
*** 148,153 ****
--- 148,154 ----
            if (saved_domain)
                tok822_free_tree(saved_domain);
            saved_domain = domain;
+           domain = 0;
        }
  
        /*
Comment 13 Carsten Hoeger 2003-08-05 16:18:13 UTC
Can I close this bug?
Comment 14 Carsten Hoeger 2003-08-06 19:40:02 UTC
fixed
Comment 15 Thomas Biege 2009-10-13 19:38:07 UTC
CVE-2003-0540: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P)