4842667 2000-02-28 07:53 /90 rader/ Postmaster
Mottagare: Bugtraq (import) <9988>
Ärende: Re: SSH & xauth
------------------------------------------------------------
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="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Message-ID: <NDBBLOBHELFGMOIEELKJMEHJCAAA.david@pybus.demon.co.uk>
Date: Sat, 26 Feb 2000 12:37:31 -0000
Reply-To: David Pybus <david@PYBUS.DEMON.CO.UK>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: David Pybus <david@PYBUS.DEMON.CO.UK>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <20000224173135.A4478@ruff.cs.jmu.edu>
How is this different to a malicous user (with root privilege) just
taking a copy of the cookie out of the connected users .Xauthority
file, placing this information into their own .Xauthority file and
then connecting to the X-server on the SSH client's side. I do not
think that there is anything particularly significant about the
possibility of Trojanning xauth. The significant point here is that,
by default, an SSH client gives too much trust to the server it is
connecting to. Perhaps consideration should be given to changing this
default such that a parameter has to be passed to SSH when a session
is started to allow X11 connections, without this parameter X11
connections are not allowed.
The issue here has nothing to do with xauth and everything to do with
the trust granted by SSH. If you use SSH to connect to boxes that you
don't trust or can't be confident are secure then you should be
concerned about this. The major threat I see here is that a rooted
box could be used to gain access to a secure box through the SSH
tunnel, even if the secure box is behind a firewall that only allows
outbound connections.
Yours, David Pybus.
-----Original Message-----
From: Bugtraq List [mailto:BUGTRAQ@SECURITYFOCUS.COM]On Behalf Of Brian
Caswell
Sent: 24 February 2000 22:32
To: BUGTRAQ@SECURITYFOCUS.COM
Subject: SSH & xauth
The default SSH configuration for SSH1 and SSH2 allow for remote
controlling of X sessions through X forwarding.
All children of the SSH connection are able to tunnel X11 sessions
through the X tunnel to the client X11 session. This is accomplished
by running xauth upon logging in.
If xauth is replaced on the server by a malicious program that does
both of the following:
- runs xauth, adding in the "correct" information allowing the
children of the session to tunnel X11 programs through the SSH
session
- runs xauth, adding in the "malicious" information, allowing a
malicious source to tunnel X11 programs through the SSH session.
With the added data in .Xauthority, a malicious source can fully
control the client X session. The malicious source can then do most
anything to the X session, from logging keystrokes of the X session,
to taking screen captures, to typing in commands to open terminals.
The only thing that is required for the client system to be
compromised is for the client to remotely log via ssh (with X11
forwarding enabled) into a compromised server.
Allowing X forwarding seems to be turned on by default in SSH1, SSH2,
and OpenSSH.
To fix this "issue" add the following lines to the SSH client
configuration. ($HOME/.ssh/config or ssh_config)
Host *
ForwardX11 no
Discussions of security flaws within X11 have been going on for years.
The "issue" in SSH X11 forwarding is not new. SSH has added to the
security of X11, but by no means does the use of SSH secure X11.
--
Brian Caswell <cazz@ruff.cs.jmu.edu>
If I could load the world into vi, the first command I would use is:
%s/Windows NT//gi
(4842667) ------------------------------------------(Ombruten)
4843024 2000-02-28 10:28 /24 rader/ Postmaster
Mottagare: Bugtraq (import) <9992>
Ärende: Re: SSH & xauth
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-Authentication-Warning: 24.67.43.232: aam396 owned process doing -bs
X-Sender: aam396@24.67.43.232
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.BSF.4.21.0002251634100.78060-100000@24.67.43.232>
Date: Fri, 25 Feb 2000 16:35:01 +0000
Reply-To: Andrey <aam396@MAIL.USASK.CA>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Andrey <aam396@MAIL.USASK.CA>
X-To: Brian Caswell <cazz@RUFF.CS.JMU.EDU>
X-cc: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <20000224173135.A4478@ruff.cs.jmu.edu>
On Thu, 24 Feb 2000, Brian Caswell wrote:
> Allowing X forwarding seems to be turned on by default in SSH1, SSH2,
> and OpenSSH.
>
It's not turned on by default for OpenSSH. SSH1 and two are defaulted
to on.
(4843024) ------------------------------------------(Ombruten)
4845193 2000-02-28 18:14 /33 rader/ Postmaster
Mottagare: Bugtraq (import) <9998>
Ärende: Re: SSH & xauth
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <200002280301.UAA09309@cvs.openbsd.org>
Date: Sun, 27 Feb 2000 20:01:41 -0700
Reply-To: Theo de Raadt <deraadt@CVS.OPENBSD.ORG>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Theo de Raadt <deraadt@CVS.OPENBSD.ORG>
X-To: Oliver Friedrichs <OFriedrichs@SECURITY-FOCUS.COM>
X-cc: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Your message of "Fri, 25 Feb 2000 14:17:26 PST."
<4036B8ED3AAED3118F9E00A0CC58F9F1873E@MAIL>
> > All children of the SSH connection are able to tunnel X11 sessions
> > through the X tunnel to the client X11 session. This is
> > accomplished by running xauth upon logging in.
>
> I'm really suprised this is still the default. I've heard mention of
> this at least 4 years ago, and have seen trojaned SSH servers around
> _since then_ that do logging of client X11 keystrokes - probably the
> best place to accomplish this. The problem seems to be that the
> authors have not figured out that this isn't a good default, perhaps
> for convenience's sake. This suprises me, since people DO know about
> this. I think the argument is really convenience vs. security (well,
> thats always the argument isn't it?).
>
> alias ssh="ssh -x"
Earlier, bugtraq was told that all ssh versions including openssh
automatically tunnel X.
This is not correct. openssh has that turned off by default.
(4845193) ------------------------------------------
4845561 2000-02-28 20:33 /42 rader/ Postmaster
Mottagare: Bugtraq (import) <10005>
Markerad av 1 person.
Ärende: Re: SSH & xauth
------------------------------------------------------------
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: <20000228083307.1044115060@mercury.cern.ch>
Date: Mon, 28 Feb 2000 09:33:07 +0100
Reply-To: Lionel Cons <lionel.cons@CERN.CH>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Lionel Cons <lionel.cons@CERN.CH>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.NEB.3.96L.1000225211428.18984A-100000@fledge.watson.org>
Robert Watson writes:
> [...]
> If you search back a few years in the bugtraq archives, you'll see that
> one suggestion for dealing with this, and still allowing X11 forwarding
> from untrusted clients, is to use the Xnest server, limiting access by the
> ssh client to that DISPLAY. [...]
This is one possibility but you have to understand how X11 works and
probably also enable and configure the X11 security extension. You may
want to have a look at /usr/X11R6/lib/X11/xserver/SecurityPolicy (or
similar path).
Another possibility is to use an X11 connection proxy with filtering
capabilities like the one I wrote, see:
http://home.cern.ch/~cons/mxconns
With mxconns, you can detect a great number of "hostile" X11 requests
before they reach your X server. I use it daily to filter what comes
out of the SSH X11 proxies that I use...
________________________________________________________
Lionel Cons http://home.cern.ch/~cons
CERN http://www.cern.ch
Instruction Booklet Governing Principle:
Instruction booklets are lost by the Goods Delivery Service. If not,
they are listed in four languages: Japanese, Thai, Swahili and Moghol.
(4845561) ------------------------------------------
4850658 2000-03-01 01:38 /41 rader/ Postmaster
Mottagare: Bugtraq (import) <10020>
Ärende: Re: SSH & xauth
------------------------------------------------------------
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
User-Agent: Mutt/1.1.2i
X-PGP-FINGERPRINT: 4AB7 A021 1E73 E140 3BFE C6ED 69CF F512 9874 403C
X-PGP-Keys: Send mail with subject "get pgp key"
Message-ID: <20000228150226.A19949@ruff.cs.jmu.edu>
Date: Mon, 28 Feb 2000 15:02:26 -0500
Reply-To: Brian <cazz@RUFF.CS.JMU.EDU>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Brian <cazz@RUFF.CS.JMU.EDU>
X-To: bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
Ok, just to make sure everyone completely understands my previous post
about SSH & xauth.
The whole issue is that by default the *SSH CLIENT* automagicly
requests xforwarding from the server if the client was run during an x
session.
The *entire* reason for the above post was NOT to alert people of a
new hole, just to make SSH users aware that by default the SSH Client
is set up to allow a trojanized server control of their x session.
This is more significant than trojanizing the SSH server. There is a
large amount of control given when X forwarding is on, far beyond the
control of just what goes on in that ssh terminal session.
For absolute security, a client should always give out trust in the
smallest portions available. Trusting X tunneling by default is not a
good idea, and should be turned off. As stated in previous postings,
if you must use X, use Xnest.
If this was unclear in my previous post to bugtraq, then I am sorry.
--
Brian Caswell <cazz@ruff.cs.jmu.edu>
I can levitate birds. Nobody cares. --- Steven Wright
(4850658) ------------------------------------------
4850739 2000-03-01 03:16 /68 rader/ Postmaster
Mottagare: Bugtraq (import) <10023>
Ärende: Re: SSH & xauth
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-OS: FreeBSD 3.4-RELEASE
X-Sender: cy
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <200002281835.KAA05769@cwsys.cwsent.com>
Date: Mon, 28 Feb 2000 10:35:55 -0800
Reply-To: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>
X-To: Theo de Raadt <deraadt@CVS.OPENBSD.ORG>
X-cc: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Your message of "Sun, 27 Feb 2000 20:01:41 MST."
<200002280301.UAA09309@cvs.openbsd.org>
In message <200002280301.UAA09309@cvs.openbsd.org>, Theo de Raadt
writes:
> > > All children of the SSH connection are able to tunnel X11 sessions
> > > through the X tunnel to the client X11 session. This is
> > > accomplished by running xauth upon logging in.
> >
> > I'm really suprised this is still the default. I've heard mention of
> > this at least 4 years ago, and have seen trojaned SSH servers around
> > _since then_ that do logging of client X11 keystrokes - probably the
> > best place to accomplish this. The problem seems to be that the
> > authors have not figured out that this isn't a good default, perhaps
> > for convenience's sake. This suprises me, since people DO know about
> > this. I think the argument is really convenience vs. security (well,
> > thats always the argument isn't it?).
> >
> > alias ssh="ssh -x"
>
> Earlier, bugtraq was told that all ssh versions including openssh
> automatically tunnel X.
>
> This is not correct. openssh has that turned off by default.
>
Theo, I held the same opinion as you until it was pointed out to me
offline that it's not the server that needs the default specification,
as it already has, and because an untrusted server could have its
specification changed. Instead the ssh_config (client) needs to have
its default changed to deny X tunnelling as well in case an untrusted
server, e.g. a server one does not trust, has its specification X
tunnelling changed to allow it.
To disable X forwarding, ssh_config also needs,
Host *
ForwardX11 no
Ultimately turning on X forwarding would require changing of
sshd_config, to enable the server X forwarding, and the users
~/.ssh/config file to enable the client's accepting of forwarded X
packets. The second half of this would put the onus on the user for
their own security, as the user would have to specifically enable X
forwarding, even though the server already has it enabled.
Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Team Leader, Sun/DEC Team Internet: Cy.Schubert@uumail.gov.bc.ca
UNIX Group, ITSD, ISTA
Province of BC
"COBOL IS A WASTE OF CARDS."
(4850739) ------------------------------------------
4850798 2000-03-01 04:57 /43 rader/ Postmaster
Mottagare: Bugtraq (import) <10032>
Ärende: Re: SSH & xauth
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
Message-ID: <20000229012547.D72CB1FAAC@lists.securityfocus.com>
Date: Mon, 28 Feb 2000 18:03:03 -0500
Reply-To: provos@CITI.UMICH.EDU
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Niels Provos <provos@CITI.UMICH.EDU>
X-To: Robert Watson <robert+sec@cyrus.watson.org>
X-cc: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Robert Watson, Fri, 25 Feb 2000 21:52:15 EST
Hi Robert,
This thread was about how default configurations can have negative
impact on security. You mention the CheckHostIP option in OpenSSH.
CheckHostIP defaults to 'yes'. It introduces only additional checks
and has not influence on permitting an SSH session to proceed. Thus it
has no negative impact on your system security.
I do not agree with your assumption that most SSH servers use dynamic
IP addresses. I believe that for the majority of users the contrary
is true. However, if you are in an environment with dynamic IP
addresses, you can turn the CheckHostIP option off.
In message <Pine.NEB.3.96L.1000225211428.18984A-100000@fledge.watson.org>, Robe
rt Watson writes:
>You can even imagine DNS-based spoofing causing some problems, if combined
>with IP spoofing, as ssh-by-ip to a spoofed host would not generate an
>unknown key warning, instead, it would connect with full trust. This
>attack is a little of a stretch on convenience for the attacker, but is
>feasible.
This is not true. If you did not authorize a (canonical hostname,
public key) binding [by inserting it into OpenSSH's knownhosts file],
you will always get a warning. Please verify your facts before you
post.
If you have questions about OpenSSH in the future, you can reach us at
openssh@openssh.com.
Greetings,
Niels.
(4850798) ------------------------------------------
4850820 2000-03-01 06:13 /52 rader/ Postmaster
Mottagare: Bugtraq (import) <10038>
Ärende: Re: SSH & xauth
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-Sender: robert@fledge.watson.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.NEB.3.96L.1000228212043.39909C-100000@fledge.watson.org>
Date: Mon, 28 Feb 2000 21:45:34 -0500
Reply-To: Robert Watson <robert+sec@cyrus.watson.org>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Robert Watson <robert@cyrus.watson.org>
X-To: David Pybus <david@PYBUS.DEMON.CO.UK>
X-cc: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <NDBBLOBHELFGMOIEELKJMEHJCAAA.david@pybus.demon.co.uk>
On Sat, 26 Feb 2000, David Pybus wrote:
> The issue here has nothing to do with xauth and everything to do with the
> trust granted by SSH. If you use SSH to connect to boxes that you don't
> trust or can't be confident are secure then you should be concerned about
> this. The major threat I see here is that a rooted box could be used to gain
> access to a secure box through the SSH tunnel, even if the secure box is
> behind a firewall that only allows outbound connections.
Since we're discussing problems with the default SSH/OpenSSH trust
model, and X11 is now considered to be risky, we might as well follow
on to the natural successor in the ``disable it due to safety''
world--the automatic forwarding of access to the authentication
agent. By default, if you make use of the authentication agent for
key management, any host you connect to will gain access to the
ability to use the authentication agent. In the untrusted server
scenario we've been discussing, this would present a significant
risk, as anyone exploiting access to the authentication agent could
gain any rights normally authorized by demonstration of the keying
material in use.
I.e., suppose you distributed a single identity.pub to a number of
hosts as authorized_key to log in. Suppose you make use of
ssh-agent, and ssh-add, to cache the keying material for use. Now
suppose one of those hosts is compromised--for the lifetime of your
ssh connection, the cracker of the compromised host can log into any
account on the other hosts using that authorized_keys.
If we're switching to a model where X11 forwarding is disabled by
default on the client, we should also consider disabling agent
forwarding, which can present a similar and significant risk.
Robert N M Watson
robert@fledge.watson.org http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services
(4850820) ------------------------------------------(Ombruten)
4850881 2000-03-01 07:37 /51 rader/ Postmaster
Mottagare: Bugtraq (import) <10044>
Ärende: Re: SSH & xauth
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-Sender: robert@fledge.watson.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.NEB.3.96L.1000228153356.37011E-100000@fledge.watson.org>
Date: Mon, 28 Feb 2000 15:37:42 -0500
Reply-To: Robert Watson <robert+sec@cyrus.watson.org>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Robert Watson <robert@cyrus.watson.org>
X-To: Theo de Raadt <deraadt@CVS.OPENBSD.ORG>
X-cc: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <200002280301.UAA09309@cvs.openbsd.org>
On Sun, 27 Feb 2000, Theo de Raadt wrote:
> > alias ssh="ssh -x"
>
> Earlier, bugtraq was told that all ssh versions including openssh
> automatically tunnel X.
>
> This is not correct. openssh has that turned off by default.
Theo,
I suspect that some clarification on your point is required, as it is
accurate only as of a recent commit to the OpenBSD CVS source
repository (Mon, 28 Feb 2000 12:52:01 -0700 (MST)). For reference, I
have attached the cvs repo commit message. Users of OpenBSD may want
to update to the latest version of these files to avoid the security
risks associated with the poor OpenSSH default setting. Of course,
this applies to all other consumers of OpenSSH who have not updated
their configurations.
Date: Mon, 28 Feb 2000 12:52:01 -0700 (MST)
From: Markus Friedl <markus@cvs.openbsd.org>
To: source-changes@cvs.openbsd.org
Subject: CVS: cvs.openbsd.org: src
Reply-To: Markus Friedl <markus@cvs.openbsd.org>
CVSROOT: /cvs
Module name: src
Changes by: markus@cvs.openbsd.org 2000/02/28 12:51:59
Modified files:
usr.bin/ssh : ssh.1 ssh.c readconf.c
Log message:
turn off x11-fwd for the client, too.
(4850881) ------------------------------------------(Ombruten)
4850895 2000-03-01 08:02 /160 rader/ Postmaster
Mottagare: Bugtraq (import) <10045>
Markerad av 1 person.
Ärende: Re: SSH & xauth
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-Sender: robert@fledge.watson.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.NEB.3.96L.1000228200902.39599A-100000@fledge.watson.org>
Date: Mon, 28 Feb 2000 21:10:06 -0500
Reply-To: Robert Watson <robert+freebsd@cyrus.watson.org>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Robert Watson <robert@cyrus.watson.org>
X-To: Niels Provos <provos@citi.umich.edu>
X-cc: Robert Watson <robert+sec@cyrus.watson.org>
BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <200002282301.SAA11531@cyrus.watson.org>
On Mon, 28 Feb 2000, Niels Provos wrote:
> This thread was about how default configurations can have negative
> impact on security. You mention the CheckHostIP option in OpenSSH.
> CheckHostIP defaults to 'yes'. It introduces only additional checks
> and has not influence on permitting an SSH session to proceed. Thus it
> has no negative impact on your system security.
Please see below for a more detailed discussion of this issue.
> I do not agree with your assumption that most SSH servers use dynamic
> IP addresses. I believe that for the majority of users the contrary
> is true. However, if you are in an environment with dynamic IP
> addresses, you can turn the CheckHostIP option off.
I did not assume that most SSH servers use dynamic IP addresses--what
I did assert is that the number of servers using dynamic IP addresses
will increase due to a number of factors, not least the increased
access to broadband connectivity in the US, and the increase in use
of personal UNIX operating systems. Many of the traditional static
IP environments are also converting to dynamic allocation due to
improved ease of management, as well as limited address space. Our
security tools should be developed with this increasingly common
environment in mind, and make use of defaults that are appropriate
for that environment.
Keep in mind also that a gradual introduction of IPv6 is occurring in
a number of frameworks--not so much in the UIS, but certainly in
other less IP-rich parts of the world. IPv6 not only assumes
renumbering, but in fact one of the goals is to make this much
easier. In IPv4 with CIDR, as in IPv6, the IP address has to do with
packet routing, identifying interfaces, not services on hosts.
> In message <Pine.NEB.3.96L.1000225211428.18984A-100000@fledge.watson.org>, Robe
> rt Watson writes:
> >You can even imagine DNS-based spoofing causing some problems, if combined
> >with IP spoofing, as ssh-by-ip to a spoofed host would not generate an
> >unknown key warning, instead, it would connect with full trust. This
> >attack is a little of a stretch on convenience for the attacker, but is
> >feasible.
> This is not true. If you did not authorize a (canonical hostname,
> public key) binding [by inserting it into OpenSSH's knownhosts file],
> you will always get a warning. Please verify your facts before you
> post.
We probably ought to take this discussion to another forum more
specific to SSH, but I'll give a brief overview of my concerns as
they rally reflect on any user-managed key type of environment--be it
PGP email, SSH, etc.
The first concern is to clearly articulate the levels of warnings
supported by SSH. Not being intimately familar with its
construction, I have observed three types of warnings:
1) Warning, without confirmation, some administrative function has
occurred
2) Warning, with confirmation, that a new key will be introduced
3) Warning, with confirmation, that a key mismatch has been observed
When I observed that certain classes of key bindings could be
instantiated without warning the user, I meant that user confirmation
was not required to expand the scope of ``addresses'' that the key
would be accepted for. While OpenSSH does display a clear warning
that it has introduced a new key binding for the IP address of an
existing Name->Key binding, it does not request confirmation--it
automatically instantiates the binding. This creation of a binding,
without requiring user confirmation, relies on a static relationship
between names and IPs. You claim that it introduces no new security
risks, but I see two: first, that it will introduce spurious errors
(type 3 from above) in a legitimate dynamic IP environment. Second,
it will allow the introduction of new bindings based on IP and DNS
spoofing.
Both of these have their risks: the first set of spurious warnings
reduces sensitivity among the user community to the risks of changing
keys--it may also require users to make key administration decisions
that they are not qualified to make--either because they do not
understand the issues sufficiently, or because they do not have
sufficient knowledge of the server infrastructure to validate the
correctness of the change.
The second risk may take advantage of the first issue, but does not
have to. Imagine that users may log into services based on either a
name or an IP address, depending on their needs. Users expect that
SSH will prompt for user confirmation during key introduction
situations, and if no confirmation is required at that time, then key
validation has already occurred. Essentially that the known_hosts
keyring reflects their validation decisions of the past. Using the
automatic key introduction technique, with DNS and IP spoofing, I can
introduce new key bindings into the key set that may result in this
assumption being incorrect.
Suppose I pursuade a user to connect to my server by name, and they
validate the key finger print. My key is now in their known_hosts,
in a valid way. If I spoof DNS and IP, I can cause OpenSSH to
introduce bindings between my key and arbitrary IP addresses
(assuming the IP addresses aren't already in the file). If the user
now attempts to connect to one of those IP addresses for a legitimate
service, and spoof IP connectinos from that IP, OpenSSH will not be
in the desired situation of prompting for new key introduction, but
instead will use the existing key without any warning. A non-fatal
advisory warning was displayed during the attack, whereas my belief
is that it should have required user intervention as it created a new
service address->key binding.
The moral of the story seems to be that key bindings should be
introduced in two situations: based on specific user confirmation of
the binding creation by providing a fingerprint, etc, or through a
trusted key introduction method such as a PKI the user has already
authorized. Automated introduction of keys in other ways may not be
appropriate in many environments, as it can generate spurious errors
(key mismatches), or can increase risk by creating the opportunity
for the key management mechanism to act in ways not parallel to the
user's security assumptions.
You can postulate that the real problem here has to do with service
naming and namespaces. The user isn't interested in the binding
between transport addresses and keys, only service names and keys.
As transport management and service name management may be
substantially different (well-known and published allocation
vs. automatic and dynamic allocation), differences between the two
namespaces should be respected. If the user approves a key binding
between a service name in one layer, and the service, they may not be
approving a binding between a name in another layer and the service.
A comparable issue in another space would be creating new bindings
between PGP keys and alternative forms of an address automatically.
For example, just because I have a PGP key associated with my email
address, robert@fledge.watson.org, doesn't mean PGP should assume
that the PGP key is appropriate for robert@204.156.12.50. In PGP, as
I believe it should be the case in SSH, unless a PKI is authorized to
introduce new name->key bindings, bdingins are individually
authorized (web of trust, whatever).
There are also some practical management considerations. With
centralized key files based on names, OpenSSH will replicate the
central keys into personal key files for the IP bindings. If servers
are renumbered, the old IP->key beindigns will persist, causing
spurious errors following a renumbering of server IPs. As address
space limits becmoe more pressing, this kind of situation will come
up more frequently.
We should take further discussion offline from a bugtraq
perspective--please send replies to me and the OpenSSH mailing list.
Robert N M Watson
robert@fledge.watson.org http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services
(4850895) ------------------------------------------(Ombruten)
4854019 2000-03-01 23:03 /53 rader/ Postmaster
Mottagare: Bugtraq (import) <10050>
Ärende: Re: SSH & xauth
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20000301050844.54D541CE8@overcee.netplex.com.au>
Date: Wed, 1 Mar 2000 13:08:44 +0800
Reply-To: Peter Wemm <peter@NETPLEX.COM.AU>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Peter Wemm <peter@NETPLEX.COM.AU>
X-To: Robert Watson <robert+sec@cyrus.watson.org>
X-cc: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Message from Robert Watson <robert@CYRUS.WATSON.ORG> of "Mon, 2
Feb 2000 21:45:34 EST.
<Pine.NEB.3.96L.1000228212043.39909C-100000@fledge.watson.org>
Robert Watson wrote:
> I.e., suppose you distributed a single identity.pub to a number of hosts
> as authorized_key to log in. Suppose you make use of ssh-agent, and
> ssh-add, to cache the keying material for use. Now suppose one of those
> hosts is compromised--for the lifetime of your ssh connection, the cracker
> of the compromised host can log into any account on the other hosts using
> that authorized_keys.
>
> If we're switching to a model where X11 forwarding is disabled by default
> on the client, we should also consider disabling agent forwarding, which
> can present a similar and significant risk.
A better and far safer way is to modify ssh-agent so that you have an
active local unix domain socket to it or something and have a
foreground "monitor" program that is required to manually authorize
the use of the agent.
I had something hacked up a while back that did just this. It sat in
an xterm in a loop and it would beep several times when an
authentication request came in via the tunnel and would prompt you
for an ack/nak for the request.
So, when you used the ssh agent you would get a few beeps and
everything would pause while waiting for the ack. Once you OK'ed it,
things would continue.
The risk is that somebody could wait for you to attempt to use the
tunnel and insert a hostile authentication request into the tunnel
and you'd ack that instead, but you'd wise up to that pretty quickly
when things didn't work or you got a duplicate request or things hung
or whatever. By then it may be too late but at least you've been
immediately alerted to the problem. I didn't see an easy way to
identify the origin of an authentication challenge.
It complicated the code somewhat and I was never entirely happy with
it. I don't think I've got the code around now, I suspect I hacked
it up in one of the FreeBSD ports work areas and later deleted it as
part of a mass cleanup. :-( It shouldn't be too hard to duplicate
though.
Cheers,
-Peter
(4854019) ------------------------------------------(Ombruten)
4857608 2000-03-02 20:18 /41 rader/ Postmaster
Mottagare: Bugtraq (import) <10085>
Ärende: Re: SSH & xauth
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-OS: FreeBSD 3.4-RELEASE
X-Sender: cy
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <200003021354.FAA03761@cwsys.cwsent.com>
Date: Thu, 2 Mar 2000 05:53:55 -0800
Reply-To: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>
X-To: Brian <cazz@RUFF.CS.JMU.EDU>
X-cc: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Your message of "Mon, 28 Feb 2000 15:02:26 EST."
<20000228150226.A19949@ruff.cs.jmu.edu>
In message <20000228150226.A19949@ruff.cs.jmu.edu>, Brian writes:
> Ok, just to make sure everyone completely understands my previous post
> about SSH & xauth.
[edited out]
> For absolute security, a client should always give out trust in the
> smallest portions available. Trusting X tunneling by default is not a
> good idea, and should be turned off. As stated in previous postings,
> if you must use X, use Xnest.
Another alternative would be to use xforward or xroute. Both are
capable of notifying you of incoming X connections and you can allow
or deny each one specifically. The downside however, is that with
either you need to trust the host that your X server is running on,
e.g. xhost x_server_machine. If you're using a desktop system that
isn't used by anyone else, you should be O.K.
Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Team Leader, Sun/DEC Team Internet: Cy.Schubert@uumail.gov.bc.ca
UNIX Group, ITSD, ISTA
Province of BC
"COBOL IS A WASTE OF CARDS."
(4857608) ------------------------------------------(Ombruten)