Date: Thu, 30 Sep 1999 07:57:42 -0700 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: Warner Losh <imp@village.org> Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, freebsd-security@FreeBSD.ORG Subject: Re: [Fwd: Truth about ssh 1.2.27 vulnerabiltiy] Message-ID: <199909301458.HAA94132@cwsys.cwsent.com> In-Reply-To: Your message of "Wed, 29 Sep 1999 21:56:21 MDT." <199909300356.VAA08428@harmony.village.org>
index | next in thread | previous in thread | raw e-mail
Thread from freebsd-security.
In message <199909300356.VAA08428@harmony.village.org>, Warner Losh
writes:
> In message <199909291438.KAA19248@khavrinen.lcs.mit.edu> Garrett
> Wollman writes:
> : It is an application bug in that temporary files created by
> : applications should always reside in a newly-created directory which
> : is owned by the appropriate user and mode 700.
>
> Having looking into this more deeply, I agree this is an ssh bug. It
> needs to verify that /tmp/ssh-user exists, is a directory, and is
> owned by user *BEFORE* trying to bind. Hacking the kernel to not
> follow symbolic links isn't the best solution here (commits to
> -current not with standing). It already creates the directoy if it
> doesn't exist... I'll have to look at the ssh code to see what a
> proper fix is.
It's interesting to note the difference in philosophy between FreeBSD
and Linux. Where FreeBSD is concerned with correctness and IMO doing
the right thing, Linux is concerned with hacking something together
that works. Hence differences in rate of development adherence to
standards. It's been reported on BUGTRAQ that Linux will have a hack
in their next kernel to "fix" this SSH bug. They've also announced
that they won't be following symlinks on mknod(2) either.
From a security standpoint this looks like it makes sense. (When I put
my security administrator's hat on I don't care what I break). Before
we go headlong into this, what are the ramifications, e.g. standards,
etc. of doing this? (When I put my manager's hat on I need to think
about the functional and business ramifications).
Maybe what we need to do, after much discussion, is to create a sysctl
flag or a per user control in login.conf to disable following symlinks
when creating sockets, device nodes, and maybe even files, e.g. one bit
in the control byte to control each of these. Then have it default one
way or the other, depending on what the FreeBSD community and
ultimately core wants.
Then there's the people factor. Giving the average administrator the
option can lead to disaster.
Then again all of this could be overkill of a very simple problem with
a very simple solution.
In short I think we need to think about this and discuss it a little
more before jumping to any conclusions.
Any thoughts?
Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Sun/DEC Team, UNIX Group Internet: Cy.Schubert@uumail.gov.bc.ca
ITSD Cy.Schubert@gems8.gov.bc.ca
Province of BC
"e**(i*pi)+1=0"
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909301458.HAA94132>