Bugtraq mailing list archives
Re: BUGTRAQ ALERT: Solaris 2.x vulnerability
From: cross () math psu edu (Dan Cross)
Date: Thu, 17 Aug 1995 06:32:37 -0400
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.
Current thread:
- Re: BUGTRAQ ALERT: Solaris 2.x vulnerability Michael Dilger (Aug 15)
- Re: BUGTRAQ ALERT: Solaris 2.x vulnerability Neil Readwin (Aug 15)
- Re: BUGTRAQ ALERT: Solaris 2.x vulnerability Dan Cross (Aug 16)
- Re: BUGTRAQ ALERT: Solaris 2.x vulnerability Neil Readwin (Aug 16)
- Re: BUGTRAQ ALERT: Solaris 2.x vulnerability Dan Cross (Aug 17)
- SunOS 4.1.x ptrace flaw Bonfield James (Aug 17)
- Re: BUGTRAQ ALERT: Solaris 2.x vulnerability Dan Cross (Aug 16)
- Re: BUGTRAQ ALERT: Solaris 2.x vulnerability Neil Readwin (Aug 15)
- Re: BUGTRAQ ALERT: Solaris 2.x vulnerability Adam Prato (Aug 15)
- Re: BUGTRAQ ALERT: Solaris 2.x vulnerability Brian Perkins (Aug 15)
- Re: BUGTRAQ ALERT: Solaris 2.x vulnerability Sam Quigley (Aug 15)
- Re: BUGTRAQ ALERT: Solaris 2.x vulnerability Alexander L. Haiut (Aug 16)
- /proc ps for Solaris 2.X Doug Hughes (Aug 16)
- Re: BUGTRAQ ALERT: Solaris 2.x vulnerability Brian Perkins (Aug 15)
- <Possible follow-ups>
- Re: BUGTRAQ ALERT: Solaris 2.x vulnerability Dan Thorson (Aug 15)
- Re: BUGTRAQ ALERT: Solaris 2.x vulnerability Aleph One (Aug 15)
- Re: BUGTRAQ ALERT: Solaris 2.x vulnerability Nathan Lawson (Aug 16)
- Re: BUGTRAQ ALERT: Solaris 2.x vulnerability Patrick Hess (Aug 16)
- Re: BUGTRAQ ALERT: Solaris 2.x vulnerability Aleph One (Aug 15)