From nobody  Wed May 13 16:30:20 1998
Received: (from nobody@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id QAA14271;
          Wed, 13 May 1998 16:30:20 -0700 (PDT)
          (envelope-from nobody)
Message-Id: <199805132330.QAA14271@hub.freebsd.org>
Date: Wed, 13 May 1998 16:30:20 -0700 (PDT)
From: trost@cloud.rain.com
To: freebsd-gnats-submit@freebsd.org
Subject: TCP-based RPC denial-of-service attack
X-Send-Pr-Version: www-1.0

>Number:         6627
>Category:       bin
>Synopsis:       TCP-based RPC denial-of-service attack
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    sheldonh
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed May 13 16:30:01 PDT 1998
>Closed-Date:    Tue Aug 17 01:14:14 PDT 1999
>Last-Modified:  Tue Aug 17 01:14:36 PDT 1999
>Originator:     Bill Trost
>Release:        current
>Organization:
Trost Computing
>Environment:
FreeBSD grey.cloud.rain.com 3.0-CURRENT FreeBSD 3.0-CURRENT #5: Mon May  4 13:42:11 PDT 1998     trost@grey.cloud.rain.com:/mnt/usr/src/sys/compile/GREY  i386

>Description:
From: Peter van Dijk <peter@ATTIC.VUURWERK.NL>
Subject:      Re: easy DoS in most RPC apps
To: BUGTRAQ@NETSPACE.ORG

On Sat, 28 Mar 1998, Peter van Dijk wrote:

> If you connect (using telnet, netcat, anything) to a TCP port assigned to
> some RPC protocol (tested with rpc.nfsd/mountd/portmap on Slackware
> 3.4/Kernel 2.0.33) and send some 'garbage' (like a newline ;) every 5
> seconds or faster, the service will completely stop responding. At the
> very moment the connection is closed, the service will return to normal
> work again.
> read(0, "\r\n", 4000)                   = 2
>
[bullshit cut]
>
> This bug can easily be exploited remotely without any special software and
> without taking any noticeable bandwidth (one packet every 5 seconds).
> This one worked perfectly for me:
> $ { while true ; do echo ; sleep 5 ; done } | telnet localhost 2049
> Replacing the sleep 5 with sleep 6 or even more shows that the service
> will then respond every once in a while.

Further examination and discussion (with Thomas Kukuk) shows that the bug
is probably in libc (and glibc?) and therefore probably affects _all_ rpc
applications using libc to do their rpc work (like, all Linux rpc
applications). Also, Wietse Venema responded today... Discussion still
starting up with him :)

The impact of this bug should not be underestimated. Anything that depends
on nfs to function can be shutdown completely (temporarily, that is) with
little or no effort... You don't need maths to see that even someone with
a simple 28k8 line can shutdown 100s of sites at the same time.

>How-To-Repeat:
See description.
>Fix:
Sorry....
>Release-Note:
>Audit-Trail:

From: Don Coleman <don@coleman.org>
To: freebsd-gnats-submit@freebsd.org, trost@cloud.rain.com
Cc:  Subject: Re: bin/6627: TCP-based RPC denial-of-service attack
Date: Thu, 21 May 1998 12:43:50 -0700

 This is not a bug, but rather a result of the definitition of ONC RPC
 plus a
 result of the common implementation of the RPC libraries
 (non-multithreaded)
 and servers we all use.
 
 The big problem is that most tcp RPC services can only handle one
 request
 at a time, so if a client is intentionally slow, or lies about the data
 it is
 going to send, it then ties up the service.
 
 A additional issue is that RPC rquests are marsharlled  into chunks of
 data
 called fragments. They are then further divided on the sender side into
 a
 "sendsise" buffer, and collected into a "recvsize" buffer on the
 receiver side.
 There is no fixed limit on the "fragment" size, and it isn't a
 particular
 type, so xdr doesn't know a type specific size limit either.   So if a
 client
 lies about how much data it's going to send, the server can't determine
 it is
 bogus.
 
 The only easy defense is to site behind a firewall or a packet filter,
 and not
 allow any "bad" people behind that protection.
 
 Throwing in a time-out for data delivery for each tcp connection could
 reduce
 the impact of unsophisticated attackers, but anyone willing to write a
 simple
 shell script (firing off lots of background processes connecting with
 telnet
 to a particular port) could easily swamp the timeout "defense".
 
 Long term, baring a change in the specification of the on-wire layout
 for how
 RPC moves data and a change in the RPC service API, a reasonably
 straight-
 forward solution is to multi-thread all the services, which requires an
 RPC
 library supporting multiple threads,  plus all the libraries which all
 the
 services use.
 
 Multithreading them will make it *much* harder for a denial of services
 attack
 to succeed, though an attack could impact the performance of a system.
 
 Particular services could be protected by using a custom svc_run()
 routine,
 which could marshal data on multiple connections, storing the data in a
 connection specific buffer, until a complete RPC request is built up,
 but
 one will need to change the service source code, as you can not use the
 tranport based RPC API, as they all read from the socket -- you need to
 use the buffer based version.
 
 don
 ---
 don@bsdi.com
 

From: Sheldon Hearn <sheldonh@iafrica.com>
To: Bill Trost <trost@cloud.rain.com>
Cc: Don Coleman <don@coleman.org>, freebsd-gnats-submit@freebsd.org
Subject: Re: bin/6627: TCP-based RPC denial-of-service attack
Date: Fri, 19 Mar 1999 13:11:15 +0200

 Hi Bill,
 
 I've tested this out with two 4.0-CURRENT boxes and can't reproduce the
 problem you reported. Have you tested this out, and if so, what setup
 and what set of commands did you actually use?
 
 Ciao,
 Sheldon.
 
Responsible-Changed-From-To: freebsd-bugs->sheldonh 
Responsible-Changed-By: unfurl 
Responsible-Changed-When: Thu Jul 1 18:28:09 PDT 1999 
Responsible-Changed-Why:  
Sheldon was the last person to follow up on this. Sounds like it might
be closeable. 
State-Changed-From-To: open->closed 
State-Changed-By: sheldonh 
State-Changed-When: Tue Aug 17 01:14:14 PDT 1999 
State-Changed-Why:  
Timed out waiting for feedback from originator. 
>Unformatted:
