5245886 2000-07-02 20:29 /112 rader/ Postmaster
Mottagare: Bugtraq (import) <11549>
Ärende: Kerberos security vulnerability in SSH-1.2.27
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
Message-ID: <200007010511.BAA16944@syrinx.oankali.net>
Date: Sat, 1 Jul 2000 01:11:09 -0400
Reply-To: "Richard E. Silverman" <slade@SHORE.NET>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: "Richard E. Silverman" <slade@SHORE.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
I am writing to report a security bug in SSH 1.2.27.
SOFTWARE AFFECTED:
SSH 1.2.27 with Kerberos authentication support compiled in
(i.e. "configure
--with-kerberos5"). I have contacted SSH Communicators Security
(http://www.ssh.com) about this, and they have just released ssh-1.2.28,
which fixes this problem.
OPERATING SYSTEMS:
all those supported by the SSH release (many flavors of Unix)
SYNOPSIS:
When logging in a user, sshd sets the user's KRB5CCNAME environment
variable to the value "none". If the user subsequently makes use of
Kerberos in that login session (e.g. does a kinit), Kerberos tickets
will be stored in a file named "none" in the current directory. This
is inappropriate and presents significant risk of disclosure of the
user's Kerberos tickets, via insecure file-sharing protocols such as
NFS or SMB, or other methods.
It is important to note that this bug occurs regardless of whether
Kerberos authentication is actually being used for the current
session; merely compiling in Kerberos support is sufficient to cause
the problem.
DETAILS:
Kerberos tickets are sensitive information, and stealing them may
allow an attacker to impersonate the legitimate user for the lifetime
of the ticket. The ticket cache is normally kept on the local host
in a directory set aside for such usage, e.g. /tmp. Placing the
Kerberos ticket cache in the current directory is a serious problem.
For example:
* Upon login, the current directory the user's home directory, often an
NFS-mounted filesystem. This means that tickets may be sent in the clear
over the network via NFS.
* Since the pathname ("none") is relative, tickets may be placed in
unpredictable locations, depending on the user's actions. Even though
Kerberos sets the protections of the ticket cache file restrictively, in
this situation they might be placed, say, in a directory with an inherited
ACL which gives read access to someone else, or on a removable medium.
The problem is especially bad because the user may never notice it.
As long as he or she stays in the same directory with the cache file,
Kerberos will operate normally. Only careful reading of the output
of klist, for example, will reveal the change.
QUICK FIX:
Change this:
[sshd.c:4296]
if (ticket)
child_set_env(&env, &envsize, "KRB5CCNAME", ticket);
to this:
if (ticket && strcmp("none",ticket))
child_set_env(&env, &envsize, "KRB5CCNAME", ticket);
FIX EXPLANATION:
This bug arises from confusion in the source code about the value of
this variable:
[sshd.c:547]
char *ticket = "none\0";
This variable holds file pathname to be used on the remote side for
the ticket cache, if a forwarded Kerberos TGT has been obtained.
There appears to be some inconsistency about how to interpret the
value of this variable. In some places, the SSH source compares
*ticket to the string "none" to determine whether a forwarded ticket
is available; e.g.:
[sshd.c:2691]
#ifdef KERBEROS
/* If you forwarded a ticket you get one shot for proper
authentication. */
/* If tgt was passed unlink file */
if (ticket){
if (strcmp(ticket,"none"))
/* ticket -> FILE:path */
unlink(ticket + 5);
else
ticket = NULL;
}
#endif /* KERBEROS */
But, setting and testing the pointer against the NULL value is also
used. In particular, here:
[sshd.c:4296]
if (ticket)
child_set_env(&env, &envsize, "KRB5CCNAME", ticket);
It is possible for this line to be reached with the ticket variable
still pointing to the string "none", which causes the problem.
- Richard Silverman
slade@shore.net
(5245886) ------------------------------------------(Ombruten)
5255349 2000-07-06 00:04 /37 rader/ Postmaster
Mottagare: Bugtraq (import) <11586>
Ärende: Re: Kerberos security vulnerability in SSH-1.2.27
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-Sender: jts28@travelers.mail.cornell.edu
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.SOL.3.91.1000705080847.15496C-100000@travelers.mail.cornell.edu>
Date: Wed, 5 Jul 2000 08:44:15 -0400
Reply-To: jts28@CORNELL.EDU
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: "Schlachter, Jake" <jts28@CORNELL.EDU>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <200007010511.BAA16944@syrinx.oankali.net>
Just posting to note that there is indeed a ssh-1.2.28 release, but
lo! also a 1.2.29. The .28 release's ChangeLog is identical to the
old .27, but the .29 lists the Kerberos fix, as well as... an update
to the License. It appears that 1.2.29 (and, likely, following 1.x
versions) will now be governed by the much more strict Version 2.x
license. This means that unless you are a student who does not
actually use ssh, you will most likely be paying for it. ssh has
quite a large following, and it is my understanding that SSH
Communications Security tried changing the 1.x license once before,
but a massive negative community action stayed their hand.
Options: qualify under the new lower wire, buy a commercial license,
use an old version, switch to OpenSSH or another variant, or perhaps,
by speaking with the voice of community, remind SSH of the intangible
benefits of being part of that community...
Question for the Group: isn't the version 1.x license the only reason
for the 1.5 protocol's continued use? (aside from compatibility
reasons, which could probably be cleaned up were it not for the ver
2.x license)
Regards,
jts28
(5255349) ------------------------------------------(Ombruten)
5257971 2000-07-06 20:05 /49 rader/ Postmaster
Mottagare: Bugtraq (import) <11614>
Ärende: Re: Kerberos security vulnerability in SSH-1.2.27
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-ID: <200007061427.e66ERDZ32704@sirppi.helsinki.fi>
Date: Thu, 6 Jul 2000 17:27:13 +0300
Reply-To: Atro.Tossavainen@helsinki.fi
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Atro Tossavainen <atossava@CC.HELSINKI.FI>
X-To: jts28@CORNELL.EDU
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.SOL.3.91.1000705080847.15496C-100000@travelers.mail.cornell.edu> from "Schlachter, Jake" at "Jul 5
2000 08:44:15 am"
Dear Jake,
> Just posting to note that there is indeed a ssh-1.2.28 release, but lo!
> also a 1.2.29.
And now, also a 1.2.30. This fixes bugs reported ages ago:
* the server accepting unsupported ciphers (notably "none") if so
requested by clients, even though the server itself wasn't compiled
with "--with-none";
* a syslog handle hogging bug that would cause problems on large
multi-user IRIX machines;
* and another bug that would sometimes truncate scp transfers.
The license issues remain as you said.
> Question for the Group: isn't the version 1.x license the only reason for
> the 1.5 protocol's continued use? (aside from compatibility reasons,
> which could probably be cleaned up were it not for the ver 2.x license)
Compatibility reasons indeed. For example, there is no AFS support for
2.x. I am aware of the fact that the support in 1.x is third-party.
Are there other free SSH2 clients than OpenSSH? Particularly, anything
for anything else but UNIX? That might also be an issue.
--
Atro Tossavainen (Mr.), Systems Analyst, contact info at URL, +358-9-19158939
The Institute of Biotechnology at the University of Helsinki, Finland employs
me, but my opinions are my own. They are welcome to them, if they want them.
< URL : http : / / www . iki . fi / atro . tossavainen / >
(5257971) ------------------------------------------