BoS: SDSC Security Bulletin 96.003

[alanc () godzilla EECS Berkeley EDU (Alan Coopersmith)]

------- start of forwarded message -------
From: tep () zoe sdsc edu (Tom Perrine)
Newsgroups: alt.security,comp.security.unix
Subject: SDSC Security Bulletin 96.003
Followup-To: comp.security.unix
Date: 26 Sep 1996 23:03:08 GMT
Organization: San Diego Supercomputer Center, San Diego CA
Message-ID: <52f23c$qvf () rosebud sdsc edu>
Summary: rpc.statd bug - attacks ongoing

-----BEGIN PGP SIGNED MESSAGE-----

SDSC Security Bulletin 96.003
Original Issue Date: 1996/09/26
Version: $Id: rpc.statd,v 1.9 1996/09/26 22:34:34 tep Exp $

Topic:  rpc.statd based attacks seen "in the wild"
________________________________________________________________________________

The San Diego Supercomputer Center (SDSC) and the Pacific Institute of
Computer Security (PICS) have detected "in the wild" and analyzed an
automated attack related to the problems with rpc.statd as discovered
from source code analysis by Andrew Gross and alluded to by CERT
Advisory CA-96.09.rpc.statd.

This advisory is furnished by SDSC, PICS and the San Diego Regional
Information Watch (SDRIW) as a public service to the Internet
community.

CERT is aware of this problem, and is reportedly working with vendors
to deal with this issue.  However, there is increasing evidence that
this attack is becoming widespread, is not easily detected by most
monitoring, and required access to vendor source code to verify that
the symptoms did indeed constitute an attack.  Therefore, SDSC, PICS
and SDRIW have decided to make this information available independently
of the CERT channels, so that users may look for this attack on their
systems and take steps to protect their systems.


I.  Description

As reported in the CERT Coordination Center Advisory
CA-96.09.rpc.statd, there is a vulnerability in some versions of
rpc.statd (rpc.statd is also known as statd on some systems).  At the
time of that advisory, there had been no reports of this vulnerability
being exploited.

At that time, it was believed that the vulnerability was limited to
being used to remove any file that the root user can remove or to
create any file that the root user can create.

In this attack, rpc.statd is passed information causing it to create a
file that has *machine code* inserted into the *filename* of the file.
This filename is sufficiently long that a buffer overflow occurs,
placing arbitrary machine code onto the stack, which is then executed.

This "grappling hook" is specific to each cpu type and operating
system combination.  The grappling hook causes a root shell to be
started, connected to the network socket of the rcp.statd process.


II.  Impact

Remote users using this exploit will receive a root shell on the
machine where rpc.statd runs.

*At this time*, the attack that was seen would only be successful on
*unpatched* Solaris 2.4 and previous versions, although (unsuccessful)
attacks have been observed on other system types.

Reverse engineering of this attack has proven that other operating
systems are vulnerable to similar, if not identical, attacks, with
only a different "grappling hook" required.  Attacks against other
operating systems have been demonstrated in the PICS laboratory.


III.  Solution

*It is hoped* that *most* vendors have fixed this problem properly
with their patches that addressed the Advisory, however, without
source of the patches, or statements from the vendors, we cannot be
sure.

The proper fix is to prohibit "/" in the pathnames of the files
created by rpc.statd, AND check the lengths of the strings and buffers
involved before doing the copy.  Just changing the buffer size or (C
language) storage type is insufficient.

Install vendor patches (where available) as described in
CA-96.09.rpc.statd and CA-96.09.README, although as noted above, this
may not completely close this vulnerability.

The Advisory may be found at:
ftp://ftp.cert.org/pub/cert_advisories/CA-96.09.rpc.statd
and the README may be found at
ftp://ftp.cert.org/pub/cert_advisories/CA-96.09.README


IV.  Detecting an attack

The following signature information is provided for general
information only.  It details one specific implementation of this
attack method.

Existence of the signature information does not mean that the attack
was successful, only that it was tried.

Non-existence of the signature information does not mean that the
attack hasn't been tried; the attackers can easily remove the files
after gaining access (and leaving other trap doors).

There is no obvious way to determine if the attack was successful,
other than system logs, tripwire databases, and cryptographic checksums
of critical software.


IV.A.  Unusual files in "/tmp"

You can look for traces of this exploit by examining the /tmp
directory for filenames that begin with .nfs, and that have long
filenames that are not printable ASCII characters.  The .nfs* files
should only exist in filesystems that are NFS-mounted, which would be
very unusual for a "/tmp" filesystem.

Note that the exploit software could (and probably will) be changed to
create this file in any directory writable by "root".

Here is a sample of what you may see (with the long lines wrapped):

% ls -l /tmp/.nfs*
total 280
- - --w-------  1 root            0 Sep  4 07:27 .nfs09???D???H???$???$???$???$?????
????????? ??? ??? ??? `?? O?*???*???*???*???#???#???????? P?*`???c??? 6?????????
? ??????????? ??????? ??????? )?????????? ??????? ??????#???#???? ;?????????????
????????????#??????????XbinXsh?tirdwr????? ??? ??? ??? ???

The fact that the file is zero-length is of no help, as the
assembly-code "grappling hook" is encoded in the *filename*, not the
file contents.


IV.B  System logs

If you aren't running tcp_wrappers and the "logging portmapper", you
will likely never even see the attack in any normal system logs.

However, if you do have these packages, you *may* see sweeps of your
network, with some hosts being probed for RPC services (rpcinfo -p),
followed by probes of services that are active (rpc.mountd, rpc.statd,
etc.)

If you are running Solaris 2.5 (with patched statd) you *may* see
system log messages similar to this:

Sep  4 10:15:37 hostname  statd[130]: attempt to create "/var/statmon/sm
//../../../../../../../../../../../../../../../../../../../../../../../../../../
../../../../../../../../../../../../../../../../../../../../../../../../../../..
/../../../../../../../../../../../../../../../../../../../../../../../../../../.
./../../../../..//../../../../../../../../../../../../../../../../../../../../..
/../../../../../../../../../../../../../../../../../../../../../../../../../../.
/../../../../../../../../../../../../../../../../../../../../../../../../../../
../../../../../../../../../../../../../tmp/.nfs09   D   H   $   $   $   $
                    `   O *   *   *   *   #   #         P *`   c    6
                            )                         #   #     ;
          #          XbinXsh tirdwr                      "


V.  Acknowledgments

Information in this bulletin was produced by Andrew Gross, Henry
Ptasinski, and Tom Perrine.

San Diego Supercomputer Center:
        http://www.sdsc.edu
Pacific Institute of Computer Security:
        http://www.sdsc.edu/GatherScatter/GSspring96/perrine.html
San Diego Regional Information Watch:
        http://www.sdriw.org


VI. Disclaimers

Copyright 1996 San Diego Supercomputer Center.

The material in this security alert may be reproduced and distributed,
without permission, in whole or in part, by other security incident
response teams (both commercial and non-commercial), provided the
above copyright is kept intact and due credit is given to SDSC.

This security alert may be reproduced and distributed, without permission,
in its entirety only, by any person provided such reproduction and/or
distribution is performed for non-commercial purposes and with the intent of
increasing the awareness of the Internet community.

Tom E. Perrine (tep () SDSC EDU) | San Diego Supercomputer Center
http://www.sdsc.edu/~tep/     | Voice: +1.619.534.5000

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMksJBhTSxpWcaAFRAQFR3QP/Qk+Ef6JTvlOv3s5EMZ6lKyo/rrAzH+lP
PMrxL6pv9pl0JrqcyAtVRSocEYeZaPxvWSfJcbUFvNJBTVWg8EMB3JEaK+vY0ESX
JEiHhlYyvNmh4wQPcwqHGYOKeXx/4gm6isO16YcNtsOjne/z6vpTflaPo4UzKHca
PlhQ23utoBY=
=3QpW
-----END PGP SIGNATURE-----

--
Tom E. Perrine (tep () SDSC EDU) | San Diego Supercomputer Center
http://www.sdsc.edu/~tep/     | Voice: +1.619.534.5000
"Ille Albus Canne Vinco Homines" - You Know Who

------- end of forwarded message -------