jpm@BNL.ARPA (06/27/84)
A few weeks ago I asked if anybody knew of bugs in the "at"
command. I got three responses which I am including below.
Sorry for not posting this sooner but this site has been
having problems and every time I get ready to create a
summary something goes wrong (the editor breaks, the disk
breaks, the Arpanet breaks, etc.).
Date: Sun, 17 Jun 84 2:56:10 EDT
From: Doug Gwyn (VLD/VMB) <gwyn@Brl-Vld.ARPA>
To: jpm@bnl.arpa
Subject: Re: bug in at command
UNIX System III and V do not have an "at" command.
UNIX System V Release 2 provides "user cron tables" which is the
same sort of facility but totally redone.
----
From: philabs!decvax!tektronix!jerryp
Date: Monday, 18 Jun 84 08:08:01 PDT
To: decvax!philabs!sbcs!bnl!jpm, jerryp
Subject: Re: bug in at command
John,
We have BSD here, so I'm not sure... but I've heard that the bug
involves quoting of the environment variables in the /usr/spool/at/*
file. In other words, our version (BSD) of "at" puts statements like this
in the /usr/spool/at/* file:
SYSPATH='/usr3/jerryp/.bin /usr/local /usr/tek /usr/ucb /bin /usr/bin'
I heard that the bug in other versions of "at" is that they don't quote
the variable strings. In other words, the file would have
SYSPATH=/usr3/jerryp/.bin /usr/local /usr/tek /usr/ucb /bin /usr/bin
...and, when atrun tries to execute the /usr/spool/at/* file, and the shell
reads a line like that, with blanks, it chokes.
--Jerry Peek, UNIX Training Instructor, Tektronix, Inc.
uucp: {allegra,decvax,hplabs,ihnp4,mit-eddie,ucbvax}!tektronix!jerryp
ARPAnet: jerryp.tek@csnet-relay
----
Date: Mon, 18 Jun 84 22:22:23 edt
From: yba@mit-athena (Mark H Levine)
To: jpm@BNL.ARPA
Subject: Re: bug in at command
The bug I am most fond of in "at" is that it did not quote shell variables
in the generated script. In more detail:
Say your prompt is set to the character greater-than, ">".
You run an "at" command creating a file in /usr/spool/at that begins:
PS1=>
which causes a syntax error in the shell, and the at file dies quickly and
quietly having done nothing. A fix to this was to force quoting of all
arguments which were invisibly set for the user in order to guarantee the
"at" command ran in the same environment in which the request was made,
that is the above would begin:
PS1=">"
----obrien@CSNET-SH.ARPA (06/28/84)
From: Mike O'Brien <obrien@CSNET-SH.ARPA> A more subtle bug (didn't see your posting first time, sorry) with the 4.2BSD version of "at" is that it runs only under the gid of your "major" group, that is, the one in /etc/passwd. If you need to do anything that involves other group permissions listed for you in "/etc/group", forget it.
dob@ihuxj.UUCP (Daniel M. O'Brien) (06/29/84)
System V Release 2 provides *both* a user-accessable cron facility via crontab(1) *and* an official version of at(1). Cron and at processing are handled in a coherent fashion by the cron(1) daemon. -- Daniel M. O'Brien AT&T Bell Laboratories IH 4A-258 Naperville, IL 60566 ....!ihuxj!dob
ras@rayssd.UUCP (07/03/84)
Sorry for not responding to the first request, but there is
another bug that may be out there on some systems, depending
on how protections are set up. These were found on V7 and 4.* BSD
systems, and the fix is easy enough.
The problem is that "at" uses the owner of the file to establish
the uid & gid of the process, and that if the spool/at directory is
writable, or (worse yet) the files themselves are writeable, an un-
authorized user could add stuff in, etc.
Similarly, if the directory is writeable, and the (ab)user finds a
willing and permissive file (owned by root, writable by all, and in
the same file system as spool/at), he or she can edit it and link it
into the spool/at directory. Similar things can happen if you allow
users to "chown" ownership away.
One fix is to make the spool/at directory 711 mode and "at" setuid
during the creat and chown, and then do a setuid(getuid()). I imagine
there are others.
--
Ralph Shaw, {allegra, decvax!brunix, linus, ccieng5}!rayssd!ras
Raytheon Co, Submarine Signal Division., Portsmouth, RI 02871guy@rlgvax.UUCP (Guy Harris) (07/05/84)
> The problem is that "at" uses the owner of the file to establish > the uid & gid of the process... Similar things can happen if you allow > users to "chown" ownership away. This is a problem on "USG" UNIX (S3, S5, etc.). Some versions of S3 and S5 have added "at", and some didn't plug this hole (they probably have since then - if they didn't, they should!). The plug was suggested to me by the same person who pointed out the hole, and is also used in the S5R2 version of "at". The setuid bit is sort of a passkey; a setuid program allows you some access to the privileges of the user owns the program file. Since "USG" UNIX allows you to give files away, this requires that the setuid bit be turned off when a file is given away (by other than the super-user), which is done. An "at" file owned by a given user also is similar; if it is given away, it should not allow the "at" job to have the privileges of the new user. The solution is to put the setuid bit on all "at" job files, and have the "at" daemon require the setuid bit to be on. If the file is given away, the setuid bit goes away, and the job is no longer valid. Any other software that uses the owner of a file to grant privileges can probably use the same trick. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy