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.
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) . peterat_private
------------------------------------------------------------------------------
1:37am up 9:35, 5 users, load average: 0.41, 0.28, 0.18
------------------------------------------------------------------------------
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:53:11 PDT