Subject: Here's a patch for a possible smap DoS problem

From: [email-masked]
Date: Mon, 3 Jul 2000 22:44:59 -0700

I was trying nessus (http://www.nessus.org/), a raw socket based
scanner tool, and I discovered that smap can be made to fill it's
spool with temporary files if it gets a SIGPIPE (broken pipe) because
of improper TCP teardown by the client.

This fixes it for me:

    --- smap.c.org  Tue Jan 13 14:56:14 1998
    +++ smap.c      Mon Jul  3 21:49:37 2000
    @@ -98,6 +98,14 @@
            alarm(timeout);
     }
     
    +static  void
    +brokenpipe()
    +{
    +  syslog(LLEV,"received SIGPIPE (broken pipe), aborting");
    +  if(tempfile != (char *)0)
    +    unlink(tempfile);
    +  smap_exit(1);
    +}
     
     main(ac,av)
     int    ac;
    @@ -170,6 +178,8 @@
                    close(sockl);
                    close(sock);
            }
    +
    +  signal(SIGPIPE,brokenpipe);
     
            if(peername(0,rladdr,riaddr,sizeof(riaddr))) {
                    syslog(LLEV,"cannot get remote host");

Am I too paranoid...?   :^)

-- 
}    __o
}  _(\<._  Tor Perkins           Send me e-mail with subject "get
} (_)/ (_) 962687534@noidDoTnet  pgp key" for automatic response.
--- smap.c.org	Tue Jan 13 14:56:14 1998
+++ smap.c	Mon Jul  3 21:49:37 2000
@@ -98,6 +98,14 @@
 	alarm(timeout);
 }
 
+static  void
+brokenpipe()
+{
+  syslog(LLEV,"received SIGPIPE (broken pipe), aborting");
+  if(tempfile != (char *)0)
+    unlink(tempfile);
+  smap_exit(1);
+}
 
 main(ac,av)
 int	ac;
@@ -170,6 +178,8 @@
 		close(sockl);
 		close(sock);
 	}
+
+  signal(SIGPIPE,brokenpipe);
 
 	if(peername(0,rladdr,riaddr,sizeof(riaddr))) {
 		syslog(LLEV,"cannot get remote host");

---

From: Ted Keller <[email-masked]>
Date: Tue, 4 Jul 2000 08:41:44 -0400 (EDT)

[To be removed from this list send the message "unsubscribe fwtk-users" in the
BODY of a mail message to [email-masked].]

Tor,

This may explain something that I and others have noted.  Periodially, I
see files "hanging around" in my smap spool directory.  It always appeared
that smap exited somehow - but never left any traces.  The message files
would be at some level completion - from not data to nearly complete
messages.  The message content does not seem to be part of the "smap
failure" process.  Later, the remote host would connect and deliver the
message properly.

I don't remember seeing left over files from my internal local hosts.

The frequency increases when load is high - but I do see left over files
periodically on low load days.

Any comments?

ted keller

---

From: Rick Murphy <[email-masked]>
Date: Tue, 04 Jul 2000 10:48:37 -0400

At 08:41 AM 7/4/00 -0400, Ted Keller wrote:
>see files "hanging around" in my smap spool directory.

I agree with Ted - this has been a problem since day one for some people. 
(I never see any dangling spool files on my BSD system, but some people see 
a number of those. I run BSD, which I think returns an error on the read 
call, not a SYSPIPE signal.

Ted, why it's not directly related to load is because it can be triggered 
by a number of external events - for example, network connectivity problems 
on the sender's end. If the timeout doesn't trigger before TCP declares the 
link down, you'll get a sigpipe.

Good catch, Tor.
         -Rick

---

From: James Fidell <[email-masked]>
Date: Tue, 4 Jul 2000 16:56:36 +0100

> link down, you'll get a sigpipe.

I've seen what I believe is the same problem in Gauntlet v5.0 on BSD/OS,
too.  I don't have access to those systems any more, but if someone does,
it might well be worth checking.

James.
-- 
 "Yield to temptation --             | Consultancy: [email-masked] 
  it may not pass your way again"    | http://www.cloud9.co.uk/james
                                     |
        - Lazarus Long               |              James Fidell

---

From: [email-masked]
Date: Tue, 4 Jul 2000 10:50:08 -0700

> I run BSD, which I think returns an error on the read call, not a
> SYSPIPE signal.

BSD may do that (I don't know) but what I was seeing is that smap was
writing when it happened, specifically it was in a fflush(stdout) when
it gets the signal.  Nessus would nail up a connection, hammer out
it's "'sploit", and FIN the connection.  But nessus was not waiting
for smap's FIN.  This was leaving smap in a constipated state, just
trying to say "250 OK...", meanwhile, nessus was long gone.

Inline with Ted's observation, smap would link it's xmaXXXXXX tempfile
to it's smaXXXXXX spool file (for smapd) as long as DATA was sent, so
for mostly complete connections, mail flow was not interrupted.
Unfortunately, it would never get around to unlinking the tempfile
because of the signal.

> Ted, why it's not directly related to load is because it can be
> triggered by a number of external events - for example, network
> connectivity problems on the sender's end. If the timeout doesn't
> trigger before TCP declares the link down, you'll get a sigpipe.

You are right, it's not directly related to load, but it might be
indirectly related.  Higher load probably means higher WAN side
traffic, which could lead to more dropped packets.  Also if you've got
more SMTP traffic, statistically you've got a better chance of seeing
the problem.

> Good catch, Tor.

Thanks.  I was lucky to have discovered a reproducible way to trigger
the problem.

-- 
}    __o
}  _(\<._  Tor Perkins           Send me e-mail with subject "get
} (_)/ (_) 962727327@noidDoTnet  pgp key" for automatic response.