HP automountd security bulletin

[dsiebert () ENGINEERING UIOWA EDU (dsiebert () ENGINEERING UIOWA EDU)]

> Digest Name:  Daily Security Bulletins Digest
>     Created:  Thu Oct 21  3:00:03 PDT 1999
>
> Table of Contents:
>
> Document ID      Title
> ---------------  -----------
> HPSBUX9910-104   Security Advisory regarding automountd

I was involved with tracking down this vulnerability and reporting it
to HP, SGI, and CERT, so I thought I'd contribute a bit more info for
those you of (justifiably!) worried about this.

The exploit code has been around for a while, but was written in a way
that made it pretty system specific and would be more difficult to build
today (because the system it was written for is getting out of date :) )
Apparently it is not the one that automountd (aka autofsd) was "fixed"
for previously.  To make our testing easier, I modified it to be general
and build and run on about any system, which would make a whole lot more
dangerous if I posted it (especially now when there are no vendor
patches available) so I will not be doing that at this time.  I will do
so later after the vendors have had a chance to do their thing.

Who is vulnerable?  As far as I know, all of the new generation
automounters (the ones that use RPC, support executable maps, and no
longer have the /tmp_mnt directory) are vulnerable.  I have only
personally tested against HP-UX 10.20 and IRIX 6.5.4, both are
vulnerable.  HP-UX 11.0 adds a wrinkle to make things harder, but I
suspect the exploit could be modified and it would still work.  I have
no reason to believe IRIX 6.5.5 changed anything to make it not
vulnerable.  I have not tested against anything else -- HP, SGI, and
CERT have a copy of the exploit, so all the vendors should have it by
now.  I know that people with e.g. Sun, IBM, etc. systems would like to
know if they are vulnerable.  So I will make the exploit available to
the moderators of Bugtraq if they wish to ask me for it, and they can
make it available to people they trust to test it on other systems, and
the findings can be reported.  I just don't think it would be fair to
the vast majority of sysadmins out there to just post it to the world
now, when there is no good fix.

The vulnerability lets anyone anywhere run anything as root on your
system.  Since it uses RPC, you can't use tcpwrappers to block it or
filter an extra port or two on your router.  Unless you have an
application level firewall or use the "deny all ; allow these few
things" type of router rules, you can get hit.  Even with a firewall,
you are still vulnerable to anyone on the inside (I hope you trust
them!)  The exploit does not require root privileges to run (but it does
require Unix, at least without a lot of work)

What can you do?  If you are running that new generation automounter,
unless/until you know for sure you are not vulnerable, I would go back
to the old generation one immediately (the one that uses /tmp_mnt)  That
one is not vulnerable.

Who is using this exploit?  Some systems at the U of Iowa were hit in
the early AM on Monday the 18th, the footprint was adding "+ +" to
/.rhosts and creating a file /tmp/bob and trying to run "inetd
/tmp/bob".  An old script kiddie script, used in many previous attacks
on various other holes.  This is the first we've seen of it, and it
seems like the vendors and CERT were very much caught off guard that
the automountd fix for the previous exploit was incomplete.

Ideally CERT would post a notice about this right away, and update it as
soon as they get info from each vendor on the results of their testing,
but unless they have changed their policies from what they were in the
past, I don't think that this is going to happen, which is why I made the
offer to send the exploit to the moderators of Bugtraq so they can
determine what other systems are or are not vulnerable.  Everyone else,
please do NOT email me about this asking me for the code, asking me if
OS XXX is or is not vulnerable, or ask me to try the exploit against one
of your systems.

I had recently been thinking about "upgrading" to the new automounter
(I had mainly been dragging my feet waiting for it to become stable on
HP-UX)  But now I don't think I ever will until they provide a way to
completely disable executable maps (and put a sanity check in the code
right before the fork() and exec(), to be extra sure no one finds a new
code path to get around the checks)  IMHO that code has no business
existing.  I wonder how many people really even make use of that
misfeature?

--
Douglas Siebert                Director of Computing Facilities
douglas-siebert () uiowa edu      Division of Mathematical Sciences, U of Iowa

I'm not too interested in caller ID.  But caller IQ, I'll pay a lot for that!