[ Search ] [ What's New? ] [ About ]
[ Bugs ] [ Misc ] [ Mailing Lists ] [ Newgroups ] [ NewsWire ] [ Papers ] [ People ]
[ Pictures ] [ Publications ] [ Responce Teams ] [ Tools ] [ Upcoming Events ] [ Web Sites ]

restore(8)
Systems Affected: SunOS 4.0, 4.0.1, and 4.0.3
Problem: A user does need to have an existing account to exploit this hole.
Solution: 1) Make restore non-setuid by becoming root and doing a chmod 750 /usr/etc/restore

This makes restore non-setuid and unreadable and unexecutable by ordinary users.

Making restore non-setuid affects the restore command using a remote tape drive. You will no longer be able to run a restore from another machine as an ordinary user; instead, you'll have be root to do so. (The reason for this is that the remote tape drive daemon on the machine with the tape drive expects a request on a TCP privileged port. Under SunOS, you can't get a privileged port unless you are root. By making restore non-setuid, when you run restore and request a remote tape drive, restore won't be able to get a privileged port, so the remote tape drive daemon won't talk to it.)

2) If you do need to have some users run restore from remote tape drives without being root, you can use the following workaround. 

cd /usr/etc
chgrp operator restore
chmod 4550 restore
This allows the use of restore by some trusted group. In this case, we used the group 'operator', but you may substitute any other group that you trust with access to the tape drive. Thus, restore is still setuid and vulnerable, but only to the people in the trusted group.

The 4550 makes restore readable and executable by the group you specified, and unreadable by everyone else.

Sun knows about this problem (Sun Bug 1019265) and will put in a more permanent fix in a future release of SunOS.


Aleph One / aleph1@underground.org
Copyright © 1996 Computer Underground Society. All rights reserved.