COMMAND
/usr/Cadmin/bin/csetup
SYSTEMS AFFECTED
IRIX 5.x, 6.0, 6.0.1, 6.1, 6.2
PROBLEM
If one does setenv DEBUG_CSETUP 1 and then runs csetup, it'll
create a file /usr/tmp/csetupLog, owned by root. Sure enough, it
follows symlinks, follows umask if file is nonexistant,
overwrites existing file keeping original permissions. csetup
will display a dialog window on startup, asking for root
password. However, one can press Cancel and it will proceed in
"read-only" mode. Perhaps it was considered to be enough
protection, so it doesn't bother dropping root priviledges.
The log file looks like:
Remote Host: xxx Address : xxx.xxx.xxx.xxx
Set Initial Timeout (objectserver) : 1
Get Lego objects Info
Finished Loading objects info
Networking Panel initialization complete!
Log file contains nice text, not just some binary crap. So from
the OS view point it's a shell script. sh will be invoked to
execute it, and it'll try to execute command called "Remote". So
we can overwrite some system binary and make some program running
as root execute it. But one has to have control over PATH for it
to be profitable. That's where Irix helps us. Some may remember
an old advisory about sgihelp, it was recommended that people
_remove sgihelp_ till patch is installed, pretty amazing, huh?
That's because all those GUI tools that run as root invoke
sgihelp without bothering to change uid first. Old sgihelp
didn't care if uid/euid=0, you can imagine what this means. New
one does drop root very early, but it doesn't solve the real
problem: many GUI tools calling external program while euid=0,
which is totally unnecessary.
So, do setenv DEBUG_CETUP 1, symlink /usr/tmp/casetupLog to
/usr/sbin/sgihelp, put infamous makesh called "Remote" first in
your PATH, run csetup. At this point sgihelp is nuked. Now
click on Help button, and enjoy. Remember to make a copy of real
sgihelp first.
Discovered by Jay (srinivas@t2.chem.umn.edu), Yuri Volobuev merely
helped him to finish off an exploit.
SOLUTION
Apply patches:
System Patch
-------- ---------
IRIX 5.2 Patch 1754
IRIX 5.3 Patch 1751
IRIX 6.1 Patch 1752
IRIX 6.2 Patch 1753
Solution is also to remove suid:
chmod u-s /usr/Cadmin/bin/csetup
Next, the file /var/tmp/csetupLog should be created with
permissions 0600. The sticky bit should also be set on /var/tmp/
(this is a good security practice in general).
# /bin/chmod 1777 /var/tmp
# /bin/touch /var/tmp/csetupLog
# /bin/chmod 0600 /var/tmp/csetupLog
(Note that the /var/tmp directory is not cleared at boot time.)
Before executing the csetup program, the root user should confirm
the existence, ownership, and the access permissions of
/var/tmp/csetupLog. Ensure that csetupLog is not linked to any
other file.
The impact of this workaround is that only the root user will be
able to use this program for its intended purpose. Privileged
users previously established using the /usr/Cadmin/bin/cpeople
program will no longer be able to do the system administration
tasks they were previously able perform using the csetup program,
but if you want to feel better, do following:
chmod u-s /usr/Cadmin/bin/*
chkconfig objectserver off
killall objectserver
cos /usr/Cadmin/bin is full of such programs as csetup.