Subject: I-D ACTION:draft-ietf-secsh-connect-12.txt

From: [email-masked]
Date: Mon, 19 Nov 2001 08:33:00 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Shell Working Group of the IETF.

	Title		: SSH Connection Protocol
	Author(s)	: T. Ylonen, T. Kivinen, M. Saarinen,
                          T. Rinne, S. Lehtinen
	Filename	: draft-ietf-secsh-connect-12.txt
	Pages		: 21
	Date		: 16-Nov-01
	
SSH is a protocol for secure remote login and other secure network
services over an insecure network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-12.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-secsh-connect-12.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-secsh-connect-12.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Markus Friedl <[email-masked]>
Date: Mon, 19 Nov 2001 17:05:18 +0100

hi, fyi: this is still the broken document.

---

From: Darren J Moffat <[email-masked]>
Date: Mon, 19 Nov 2001 09:22:36 -0800

> http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-12.txt

I know this was the one submitted before I got your comments, it takes
about a week from sending the email before they actually show up.  The
process seems to be very slow at this time of year ;-)

I'm submitting the version with your comments today.

---

From: Simon Tatham <[email-masked]>
Date: Wed, 21 Nov 2001 09:48:34 +0000

> 	Title		: SSH Connection Protocol
[...]
> 	Filename	: draft-ietf-secsh-connect-12.txt

Markus has just drawn my attention to section 4.4, which I hadn't
noticed before. I've got one small comment on it:

| Typically, each machine will have a preconfigured set of variables
| that it will allow. Since uncontrolled setting of environment
| variables can be very dangerous, it is recommended that
| implementations allow setting only variables whose names have been
| explicitly configured to be allowed.

Surely uncontrolled setting of environment variables is only
dangerous if you do it while you're still running as root? I was
under the impression that all the problems in Telnet's environment
passing mechanism have come up because telnetd invokes login to
authenticate the user, so login runs as root with all the user's
environment variables available. Whereas the typical SSH server will
do the uid change itself, so it can set the environment variables
_after_ it changes uid and then the only person who can be hurt by
malicious or incompetent setting of (e.g.) LD_PRELOAD is the user
themself.

I'm sure there are some SSH servers, or some situations, in which
this won't be the case, but it seems far from obvious to me that the
above text is appropriate for every implementation or even for the
typical ones. Have I misunderstood?

If I haven't misunderstood anything, then perhaps an alternative
wording might be:

| Uncontrolled setting of environment variables in a privileged
| process can be a security hazard, so it is recommended that
| implementations either maintain a list of allowable variable names,
| or do not actually set the variables until after the server process
| has dropped its privileges.

Cheers,
Simon
-- 
Simon Tatham         "_shin_, n. An ingenious device for
<[email-masked]>    finding tables and chairs in the dark."

---

From: Darren J Moffat <[email-masked]>
Date: Wed, 21 Nov 2001 08:43:27 -0800

> | has dropped its privileges.

I think that wording is much more appropriate, since it actually
describes the problem as well as giving solutions.

--
Darren J Moffat

---

From: "Joseph Galbraith" <[email-masked]>
Date: Wed, 21 Nov 2001 10:00:35 -0700

> describes the problem as well as giving solutions.

I prefer this wording as well -- unless people
feel we can remove it completely.

It seems acceptable to have a implementation note
to me.

- Joseph

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 26 Nov 2001 15:45:24 -0500

> | has dropped its privileges.

comments:

(personal observation, wg chair hat off)

Unrestricted setting of environment variables, even *after* the daemon
process sets apparently-appropriate privileges, could conceivably also
cause trouble when sshd is used to implement restricted environments
rather than give full shell access -- I'm thinking of setups like the
ones you can build with the `command="..."' option in the
authorized_keys file)... i.e., it would be a Good Thing for server
implementations to allow fine-grained control over what environment
variables can be set).

(wg chair hat on).

The IETF is primarily about wire protocols, not implementations.
environment variables are very much a local matter.  In particular,
while we can make vague recommendations, exactly when and where it's
"safe" to allow environment variables to be set is inherently
implementation specific.

Any comments on this text?

   Uncontrolled setting of environment variables can be a security
   hazard.   It is recommended that implementations exercise due care
   with requests to set environment variables, possibly including
   some form of fine-grained control over which variables may be set.

					- Bill