COMMAND

    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.