No subject

[utzoo!decvax!ucbvax!unix-wizards]

>From SomeoneOnUUCP at Berkeley Tue Sep  1 17:06:53 1981
Eps at UCLA-SECURITY reports an ingenious cure for an at(1)/atrun
security problem.  However, if /usr/spool/at remains publicly
writable, anyone can still use ln(1) and mv(1) to schedule
other's programs to execute any desired number of times (includ-
ing never) and at any times desired.

Eps also pointed out the security hazard of exec[lv]p(2) search-
ing the current directory before searching the standard system
places.  For about two weeks, Duke's default PATH has been
$HOME/bin:/bin:/usr/bin:, which causes a search of the user's
private bin, then the system places, and finally the current
directory.  (We fixed a bug in the distributed UNIX-V7 sh(1)
which causes the trailing ":" to be ignored.) The new PATH
results in faster execution, improved security, and (we think)
less confusion among the users.

We claim that ALMOST ANY file which is publicly writable is in-
secure.  This may be self-evident to some; however, here are two
obscure examples as further evidence:

1) If /usr/spool/mail is publicly writable, then anyone can be-
come the super-user.  It may seem unlikely that /usr/spool/mail
would be publicly writable, but two major VAX systems which we
checked had this flaw.  (And we only checked two!)

2) /dev/tty* should not be generally writable.  This was driven
home to Duke users when one student discovered that some "smart"
terminals could be convinced to send anything on their screens to
the computer just as if it had been typed by the user.  Access to
other's terminals should be via commands such as write(1), which
should be beefed up and made SUID.

                 James Ellis  (decvax!duke!jte)
                 Tom Truscott (decvax!duke!trt)