Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems

From: [email-masked] (Greg A. Woods)
Date: Tue, 13 Mar 2001 22:51:09 -0500 (EST)

[ On Tuesday, March 13, 2001 at 22:20:53 (+0100), Markus Friedl wrote: ]
> Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems
>
> On Tue, Mar 13, 2001 at 02:20:46PM -0500, Greg A. Woods wrote:
> > There are a zillion ways on most server-type platforms to do such
> > indirection without having to integrate it into SSH, not to mention that
> > almost all of those alternatives would then lead to total independence
> > of SSH and thus total portability across all generic transport protocols.
> 
> sftp _is_ total independeny of SSH and runs portable across
> all generic transport protocols.

Well, maybe, but sftp, at least in SSH, currently relies on the
"built-in subsystem" feature.

I'm sure you could rip it out and make it stand alone (eg. work over
rsh), but hmmm... wouldn't doing so also make it independent of the
"built-in subsystem" in SSH?  Duh!  So yes:

> > The "built-in subsystem" feature is bad design.  It has no business
> > being directly in the transport protocol.  It is an ugly wart.
> 
> tell [email-masked], not me, i don't care.

I tried but the address either you or someone else supplied originally
in this thread contained a typo and my message bounced.  :-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <[email-masked]>      <robohack!woods>
Planix, Inc. <[email-masked]>; Secrets of the Weird <[email-masked]>

---

From: Jason R Thorpe <[email-masked]>
Date: Tue, 13 Mar 2001 20:25:49 -0800

> "built-in subsystem" feature.

Actually, I don't think that's so -- it only needs a bi-directional,
stream-oriented communication endpoint, right?  "Subsystem" is merely
the mechanism that the SSH protocol uses to create that endpoint and
start the SFTP server.

...at least, that's how I understand it.

Now, a given implementation may choose to make the SFTP server
a built-in of the SSH server -- but that is not required.

 > > > being directly in the transport protocol.  It is an ugly wart.

...but I'm not sure I completely agree with this.  I can understand the
argument, but I'm not sure I buy it :-)

I think the problem is the terminology -- "subsystem" ... I think the
term "service" would be better ("Hi, please run this service over this
secure transport"), maybe, but it's probably a little too late to change
it.

-- 
        -- Jason R. Thorpe <[email-masked]>

---

From: Mats Andersson <[email-masked]>
Date: Wed, 14 Mar 2001 09:02:20 +0100 (MET)

Hi,

On Tue, 13 Mar 2001, Greg A. Woods wrote:
> I'm talking about the protocols, not the implementation.  In SSH-v2
> the SFTP application uses the "built-in subsystem" feature of the
> SECSH protocol.  I.e. it is not independent of SSH -- it relies on an
> inherent feature of the transport protocol.
...
> > > being directly in the transport protocol.  It is an ugly wart.

Good, since we're speaking about the protocols here, this is the only
mention of subsystems in the sftp draft I'm aware of:

...
When used with the Secure Shell protocol suite, this protocol is intended
to be used from the Secure Shell Connection Protocol as a subsystem, as
described in [SECSH-CONN], Section ``Starting a Shell or a Command''. The
subsystem name used with this protocol is "sftp".
...

As you may see this indeed does not state any dependency, it only gives a
recomendation for intended usage. You might also have noticed (since I
assume you indeed have read the drafts) that the subsystem feature is not
part of the transport protocol, it is a (very tiny, one could add) feature
in the connection protocol. You have almost surely also seen that one
argument was that a subsystem might be built into the ssh server which is
probably one good reason for having it in the spec.

Apart from this, you are of course also free to define whatever other
fancy "independent" protocols you might think of either as subsystems or
as ordinary "independent" servers running across stdio (one might note
here that there is no difference in practice as for how these should work
since both only "see" a stream to its peer).

So, what do I want to say with this? Well, people that have different
oppinions/suggestions/improvements/complaints on different implementations
in general and on the protocols in particular should at least have read
the specs (one could add thouroughly here...).

Cheers,

/Mats

---

From: Markus Friedl <[email-masked]>
Date: Wed, 14 Mar 2001 09:38:00 +0100

> "built-in subsystem" feature.

implementation bug or feature.  the sftp from OpenSSH works
over SSH protocol v1, too.  running sftp over rsh is simple, too.
scp speaks rsh over a transport layer, sftp speaks filexfer
over a transport layer.

-m

---

From: Markus Friedl <[email-masked]>
Date: Wed, 14 Mar 2001 09:49:55 +0100

On Tue, Mar 13, 2001 at 08:25:49PM -0800, Jason R Thorpe wrote:
> stream-oriented communication endpoint, right?

yes, you are right.

>  "Subsystem" is merely

you could use a "exec" request as well, but then you need to have
sftp-server in the path or know the full pathname on the remote host
(OpenSSH's sftp client allows this as a proof of concept). "subsystem"
just allows an additional level of indirection. it also allows easy
restriction, e.g. a user is allowed to send request only for this
and that subsystem.

> a built-in of the SSH server -- but that is not required.

this is useful if you need tighter control over the 'sftp server process'

> secure transport"), maybe, but it's probably a little too late to change

the term "service" is alreay used at a different layer.
currently there are 2 "services" defined:
	"ssh-userauth"
and
	"ssh-connection"

However, I think that the term "connection" is a little bit confusing,
since the "SSH Connection Protocol" draft only talks about "channels", so
it's really a "SSH Channel Protocol" (e.g. draft-ietf-secsh-channel).

-markus

---

From: Markus Friedl <[email-masked]>
Date: Wed, 14 Mar 2001 10:54:16 +0100

On Tue, Mar 13, 2001 at 11:00:17PM -0500, Greg A. Woods wrote:
> > No, it is a robust way of specifying server systems without having to
> > rely on locations of binaries, etc.
> 
> [...]
>
> Point of fact is that this silly protocol wart did not make OpenSSH more
> robust [...]

If you are talking about "protocol warts", then you should really read
the spec again. "subsystem" is more general then both "shell" or
"exec", so it's no "protocol wart" at all.

-m

---

From: Damien Miller <[email-masked]>
Date: Wed, 14 Mar 2001 22:45:42 +1100 (EST)

> "built-in subsystem" in SSH?  Duh!  So yes:

It is not a matter of "ripping" anything out - sftp is already
completely independant.

-d

-- 
| Damien Miller <[email-masked]> \ ``E-mail attachments are the poor man's
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer

---

From: [email-masked] (Greg A. Woods)
Date: Wed, 14 Mar 2001 14:29:00 -0500 (EST)

[ On Wednesday, March 14, 2001 at 09:02:20 (+0100), Mats Andersson wrote: ]
> recomendation for intended usage.

Well, for any amount of inter-operabiltiy it certainly does imply
complete dependency.  For example no SSH-v2.x implemention which follows
this recommendation can possibly inter-operate with any other
implementation which does not.

> You might also have noticed (since I
> in the connection protocol.

Yes, but it it a wart none the less which leads to inter-operatibility
problems that have already been seen "in the field."

> You have almost surely also seen that one

And I've already countered that argument showing that it is totally bogus.

> since both only "see" a stream to its peer).

... leading to even more critical inter-operability problems....

-- 
							Greg A. Woods

---

From: [email-masked] (Greg A. Woods)
Date: Wed, 14 Mar 2001 14:43:49 -0500 (EST)

[ On Wednesday, March 14, 2001 at 09:49:55 (+0100), Markus Friedl wrote: ]
> you could use a "exec" request as well,

Exactly.

> but then you need to have

"In the path" or by way of any other suitable platform-specific
mechanism to find an appropriate administrator-defined program matching
the request.

> "subsystem"
> just allows an additional level of indirection.

That extra indirection has no benefit.  First off since as yet there's
no registry set up (or even hinted at) to define these names there's
inevitably going to be conflict because any name can mean anything
(unless perhaps it's defined in some other approved and *referenced*
RFC).  Only negative impact will result from these already visible
inter-operability problems without.  Even with a proper subsystem name
registry (eg. through IANA) the the danger of such naming schemes in
higher level protocols are visible in numerous existing IETF approved
protocols (eg. MIME).

> it also allows easy

I'm not sure there's any real security there, and my instinct says
there's not....  Unfortunately this is an implementation specific
problem and something the protocol specifications will have a hard time
mandating (you can mandate security all you want but unless the people
making it work are 101% successful your mandate is useless and turns
into a very dangerous false sense of security where there is in fact
none).

In any case given specific implementation details it's fairly likely
that one can imagine an exploit where damage of some sort can be done
even if the remote client user is restricted to using any given
"built-in subsystem".  This is particularly true of a file transfer
style of application which permits arbitrary file types to be transfered
(or to which the real file type can be masked).

-- 
							Greg A. Woods

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 14 Mar 2001 15:05:30 -0500

> First off since as yet there's
> RFC).  

See the IANA considerations section of
draft-ietf-secsh-architecture-07.txt, section 7, which is referenced
from the various other drafts.

   "Names with the at-sign ('@') in them are allocated by the owner of DNS
    name after the at-sign (hierarchical allocation in [RFC-2343])."

Subsystem names aren't currently explicitly listed there but we can
(and should) fix that easily enough.

						- Bill

---

From: Damien Miller <[email-masked]>
Date: Thu, 15 Mar 2001 11:07:51 +1100 (EST)

> problems that have already been seen "in the field."

Rubbish - your example of a misconfigured sshd doesn't count. Should we
perhaps start regarding misconfigured inetd's as evidence of the brokenness
of TCP?

-d

---

From: [email-masked] (Greg A. Woods)
Date: Thu, 15 Mar 2001 12:19:16 -0500 (EST)

[ On Wednesday, March 14, 2001 at 15:05:30 (-0500), Bill Sommerfeld wrote: ]
> (and should) fix that easily enough.

That would certainly help, but it does not excuse the fact that this
"subsystems" feature is still an unnecessary wart that will only cause
more interoperability problems than it fixes (see my posting of moments
ago to the SSH list).

-- 
							Greg A. Woods

---

From: Markus Friedl <[email-masked]>
Date: Thu, 15 Mar 2001 18:34:24 +0100

> more interoperability problems than it fixes (see my posting of moments

why do "subsystems" cause more problems than "shell" or "exec"
especially since "subsystems" is much more general than "shell",
so "shell" could be really a 'special' kind of "subsystem"?

so "shell" is unnecessary, "subsystem" is not.

-m

---

From: K S Braunsdorf <[email-masked]>
Date: Sat, 17 Mar 2001 15:18:43 -0600

[WRT draft-ietf-secsh-connect-09.txt and recent comments.  -- ksb]

I know I'm not a regular speaker here, I just lurk a lot.  Take my views for
what they are worth.

Using a `subsystem' must be different than remote execution of a shell
command -- because we already have a way to do that.  In section 4.5 we
either start a shell, an exec, or a subsystem and I think I see why we
want each:
	+ the shell lets the service indirect though a local mechanism
	  to pick the program to run,

	+ the exec lets the client (implementor or user) pick the program
	  to run,

	+ the subsystem lets the implementor of the secsh service pick
	  the program to run.

So a `subsystem' I view more like a well known service that is provided to
the client *without* need for the client side to know the server side details
of how it is executed.

So the specification should say exactly that.  We send the name of the
subsystem we want, the server finds it and starts it.  All this talk about
filtering output from the startup of the subsystem is misplaced -- the server
implementation has to manage that startup because we (the client) don't know
how it happens.

> restriction, e.g. a user is allowed to send request only for this

We have a way to limit what a login can run on any system I've ever used (be
it UNIX's rwx, PC physical access, or RACF rules).  We don't need to create
another: clients can ask for a subsystem by name and the server can check
with the (already negotiated) credentials.

I really don't like the hack of trying to put a cookie in the output stream;
moving the file descriptors (or similar) is a much more sane tactic.  I don't
think we should put the burden on the client to make up for poor server
implementations.

But the point is that the specification should not force the client to filter
for any cookie in any case -- it should be contained to the server's startup
code because the server "has the ball" for subsystem startup.

--
ksb

---

From: [email-masked] (Niels M�ller)
Date: 19 Mar 2001 11:48:12 +0100

> 	+ the exec lets the client (implementor or user) pick the program

The difference is probably smaller than you think. If SHELL is the
user's login shell, typically

  "shell" means execl(SHELL, SHELL, NULL)

  "exec" means execl(SHELL, SHELL, "-c", COMMAND, NULL)

So in _both_ cases, the login shell and its $PATH is involved. And it
more or less has to be, if you want to support sending a command
_line_ to the server.

Hmm, the spec doesn't say explicitly that command is a command line,
but I believe that is what is intended. I.e. "grep foo
/var/log/messages | sort" is a reasonable command to use with exec. In
a less platform-specific way, I think one could say that a command
that is reasonable for system() on the server platform is also
reasonable for the "exec" request .
 
> 	+ the subsystem lets the implementor of the secsh service pick

The implementor can also choose to implement it as a part of the same
server. Of course, it's _possible_ to look at the command line for
"exec" and recognize some commands to be implemented internally, but
it is a lot cleaner to do that with "subsystem" than with "exec". I
think that is the main justification for "subsystem".

> think we should put the burden on the client to make up for poor server

I agree completely.

/Niels