(bugtraq) DoS attack against Sun RPC

[Zack Weinberg <zack@rabi.phys.columbia.edu>]

There's been some discussion of a serious security problem with Sun
RPC.  Specifically: 

# 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.

The reporter says our implementation is vulnerable.  I don't know that
code at all, but we should investigate.

zw

------- Forwarded Message

Date:    Fri, 15 May 1998 02:35:52 +0200
From:    Peter van Dijk <peter@attic.vuurwerk.nl>
To:      BUGTRAQ@NETSPACE.ORG
Subject: Re: easy DoS in most RPC apps

Finally, I'm quite sure of this: the bug is in Sun's RPC code.
Investigations show Linux, FreeBSD, SunOS, System V and NeXTstep machines
are affected, which means we've got a _big_ problem here.
Affected applications include nfsd, ypserv, ypbind and portmap. Whole
networks could be brought down easily by doing this DoS on the nfsd and/or
ypserv. If the site depends on NIS for the userlists, mail and ftp won't
work during the attack.

Greetz, Peter.

On Tue, 12 May 1998, Peter van Dijk wrote:

> Update: I tested the same trick on two NeXT Mach's. The portmapper is
> vulnerable there, as are possibly other services. NFS is not (not
> directly, a non-working portmapper does have it's effect) because it only
> uses UDP.
>
> Also, ftp.kernel.org (which runs Linux, I assume) is vulnerable ;(
>
> Greetz, Peter.
>
> On Mon, 11 May 1998, Peter van Dijk wrote:
>
> > 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 an
d
> > > 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.
> >
> > CERT: shouldn't you advise on this?
> >
> > Greetz, Peter.
> >

------------------------------------------------------------------------------
 'Selfishness and separation have led me to   .      Peter 'Hardbeat' van Dijk
  to believe that the world is not my problem .    network security consultant
  I am the world. And you are the world.'     .               (yeah, right...)
          Live - 10.000 years (peace is now)  .        peter@attic.vuurwerk.nl
------------------------------------------------------------------------------
  4:00am  up 1 day,  8:14,  4 users,  load average: 0.36, 0.10, 0.02
------------------------------------------------------------------------------


------- End of Forwarded Message