[12119] in bugtraq
Re: [Fwd: Truth about ssh 1.2.27 vulnerabiltiy]
daemon@ATHENA.MIT.EDU (Jeff Long)
Tue Oct 5 14:11:38 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <37F8E8B2.C9E8816C@kestrel.cc.ukans.edu>
Date: Mon, 4 Oct 1999 12:49:38 -0500
Reply-To: Jeff Long <long@KESTREL.CC.UKANS.EDU>
From: Jeff Long <long@KESTREL.CC.UKANS.EDU>
X-To: Rush Carskadden <rcarskadden@lightrealm.com>
To: BUGTRAQ@SECURITYFOCUS.COM
If I understand your question correctly, the agent code only does a
chown on the directory where the socket will be stored. Plus it only
does the chown if it had to create the directory (as root).
Hard links are also not a problem as bind() doesn't overwrite existing
files and you can't create a hard link (using ln) to a non-existing
file.
At least this is how it all appears to work on Digital/Compaq Tru64
Unix.
Jeff Long
Rush Carskadden wrote:
>
> I don't have Digital, nor do I fully understand the order that things
> get executed, but wouldn't it be possible to create a hardlink to a file
> that I (as a user) want access to in /tmp/ssh-<username> , allow it to
> get chown'd to me, then do as I please? It seems as though regardless of
> the protection from the symlink problem, my file still gets chown'd.
> Please forgive (educate) me if I am missing something.
<snip>
> Seeing the race problems with the previous two patches I thought I would
> take a shot at one. It changes the effective uid/gid to the user
> logging in before doing the bind() (and then resets them after) which
> seems to take care of the problem. It also chown's the
> /tmp/ssh-<username> directory before doing the bind in the case that it
> did not already exist so that the user owns it before performing the
> bind. On Digital Unix 4.0D this seems to take care of the problem. The
> bind() will fail if a symlink exists to a file that the user would
> normally not be able to write to (such as /etc/nologin). The only other
> difference after logging in is that the socket will now be owned by the
> user instead of root but I can't think of a reason why this would be
> bad.
>
> If anyone sees problems in this patch please let me know.
>
> Jeff Long
