Re: BUGTRAQ ALERT: Solaris 2.x vulnerability

[cross () math psu edu (Dan Cross)]

> setuid is not the issue - any program that creates files in /tmp and
> reopens them may be vulnerable. That includes basic things like /bin/sh
> (for << documents), so if root ever runs a shell script then an attack may
> be possible.

Hmm...  I had not put any thought to that possibility.  (many many hours of
staying awake do that.  ;-)  However, I would still think that a list of
strictly setuid programs would be a benefit, if for no other reason that one
is much more likely to be attacked through such a thing as opposed to a
``normal'' shell script or what not.  Of course, any such list would be
incomplete at best, and thus worth very little...  You are right, a better
solution is needed.

> If the sticky bit is not set on /tmp then you are toast - end of story.

Yes...  the sticky bit on /tmp is a good start, but, perhaps not enough?
For instance, the binmail race condition that popped up a few months ago
was exploitable wether or not you had the sticky bit set...

While that hole was due to poor programming (or, more precisely, no thought
given to the security implications of using that method for allocation of
temporary files), I'll wager that there are other such holes just waiting
for an aggressive cracker to discover.  Therefore, I think that a decent
solution would be to provide two ``temp'' directories..  One for public use,
and the other for secure use.  (ie, when root is the one creating the temporary
file..)  This would be simple to accomplish, the UNIX file access primatives
are all that is required (just make the directory mode 0700 and owned by root)
To go even further, the ``public'' temporary file directory could be subdivided
as Thomas Koenig proposed in another message.  Of course, for ease of adminis-
tration, one could put root's directory in with the rest, as well.

THEM simply applying the sticky bit to /tmp would solve the security problems
of a user unlinking another users files...

        - Dan C.