From owner-freebsd-security  Sun Jun 22 21:46:52 1997
Return-Path: <owner-security>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id VAA11260
          for security-outgoing; Sun, 22 Jun 1997 21:46:52 -0700 (PDT)
Received: from biggusdiskus.flyingfox.com (biggusdiskus.flyingfox.com [206.14.52.27])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA11255
          for <freebsd-security@FreeBSD.ORG>; Sun, 22 Jun 1997 21:46:50 -0700 (PDT)
Received: (from jas@localhost)
	by biggusdiskus.flyingfox.com (8.8.5/8.8.5) id VAA19002;
	Sun, 22 Jun 1997 21:46:04 -0700 (PDT)
Date: Sun, 22 Jun 1997 21:46:04 -0700 (PDT)
From: Jim Shankland <jas@flyingfox.com>
Message-Id: <199706230446.VAA19002@biggusdiskus.flyingfox.com>
To: danny@panda.hilink.com.au
Subject: Re: Simple TCP service can hang a system (fwd)
Cc: freebsd-security@FreeBSD.ORG
Sender: owner-security@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Daniel O'Callaghan <danny@panda.hilink.com.au> quotes Willy TARREAU
<tarreau@AEMIAIF.IBP.FR> as follows:

> I've noticed that inetd doesn't check the source port for the request
> to UDP simple services (echo, time, chargen, daytime).
> 
> This means it is possible to build a packet which will look like it
> comes from one of these ports, to one of these ports. In this case,
> each UDP response from the simple service will generate a new request
> to the source port and the system or network can be quickly
> overloaded.

Of course, I don't see any reason to make these services available
across administrative boundaries (or zones of trust), anyway.  They're
routinely firewalled off anywhere I've been around :-).

Jim Shankland
Flying Fox Computer Systems, Inc.