Subject: Re: Additional AD Comment: draft-ietf-secsh-publickey-subsystem and garbage

From: Joseph Galbraith <[email-masked]>
Date: Thu, 31 Aug 2006 08:33:37 -0600

Sam Hartman wrote:
> 
> I'd like to draw your attention to a particularly annoying  part of RFC 4254:
> 
>       This last form executes a predefined subsystem.  It is expected that
>       these will include a general file transfer mechanism, and possibly
>       other features.  Implementations may also allow configuring more such
>       mechanisms.  As the user's shell is usually used to execute the
>       subsystem, it is advisable for the subsystem protocol to have a
>       "magic cookie" at the beginning of the protocol transaction to
>       distinguish it from arbitrary output generated by shell
>       initialization scripts, etc.  This spurious output from the shell may
>       be filtered out either at the server or at the client.
> 
> In order to guarantee interoperability, your subsystem needs to be
> able to filter out leading garbage and clients MUST do so.
> 
> The spec doesn't currently do this.

I think the version packet can serve this purpose.

Something like this inserted in the version packet
description:

Implementations SHOULD use the first 15 bytes of
the version packet as a "magice cookie" (see RFC
4252, Section Xxx) to avoid processing spurious
output from the users shell.  These bytes will
always be:

0x00 0x00 0x00 0x0F 0x00 0x00 0x00 0x07 0x76 0x65
0x72 0x73 0x69 0x6F 0x6E

(Someone should check my hand encoding of the version
packet-- note that the actual version packet has an
additional four bytes which are the actual version number--
I didn't include this in the magic cookie because
it isn't constant.)

Thanks,

Joseph

---

From: Joseph Galbraith <[email-masked]>
Date: Thu, 31 Aug 2006 08:38:52 -0600

Jon Bright wrote:
> I'll admit to having overlooked that.  Would
> 
> 00 00 00 07 76 65 72 73 69 6f 6e
> 
> ('string "version"' in SSHish), which both sides send on start, be 
> sufficient as a magic number?
> 
> If so, I can just add a sentence referring to the garbage filtering and 
> pointing out that some garbage may appear before this byte string.

Hah... we crossed in the mail :-)

Actually, having thought about it a little more, I suspect
that in practice the byte string 00 00 00 (the first three
valid protocol bytes) would be sufficient to filter out
99.99999% of all shell output.

Thanks,

Joseph

---

From: Jon Bright <[email-masked]>
Date: Thu, 31 Aug 2006 16:33:52 +0200

-- 
Jon Bright
Silicon Circus Ltd.
http://www.siliconcircus.com

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 31 Aug 2006 09:56:07 -0500

> able to filter out leading garbage and clients MUST do so.

The text you quote says "advisable" and "may."

It is typically a misconfiguration to have user shells output anything
when there is no tty, and sysadmins bloody well know this -- users
don't though, which is why it's advisable to have this protocol feature,
but it certainly isn't REQUIRED by the text you quote.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 31 Aug 2006 08:52:03 -0400

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 31 Aug 2006 15:00:04 -0500

On Thu, Aug 31, 2006 at 03:39:25PM -0400, Sam Hartman wrote:
> >>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:
> 
>     Nicolas> On Thu, Aug 31, 2006 at 08:52:03AM -0400, Sam Hartman
>     Nicolas> wrote:
>     >> This last form executes a predefined subsystem.  It is expected
>     >> that these will include a general file transfer mechanism, and
>     >> possibly other features.  Implementations may also allow
>     >> configuring more such mechanisms.  As the user's shell is
>     >> usually used to execute the subsystem, it is advisable for the
>     >> subsystem protocol to have a "magic cookie" at the beginning of
>     >> the protocol transaction to distinguish it from arbitrary
>     >> output generated by shell initialization scripts, etc.  This
>     >> spurious output from the shell may be filtered out either at
>     >> the server or at the client.
>     >> 
>     >> 
>     >> In order to guarantee interoperability, your subsystem needs to
>     >> be able to filter out leading garbage and clients MUST do so.
> 
>     Nicolas> The text you quote says "advisable" and "may."
> 
> Yes.  The server MAY spew random garbage.  So, the client MUST deal
> with it.

Again, "it is advisable for the subsystem protocol to have a "magic
cookie" ..."

That is, there's no requirement for a magic cookie.  And there is no
RFC2119 'MAY' about user shells spewing garbage.

That said, I believe the answer that the version packet is like such a
magic cookie should suffice, no?

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 31 Aug 2006 17:35:09 -0400

> RFC2119 'MAY' about user shells spewing garbage.

I think this argument is pointless.  Since the obvious solution has been 
proposed (twice, I think), and no one seems to object, what does it matter 
how strong the requirement is?

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Thu, 31 Aug 2006 15:40:48 -0400

>>>>> "Joseph" == Joseph Galbraith <[email-masked]> writes:

    Joseph> Hah... we crossed in the mail :-)

    Joseph> Actually, having thought about it a little more, I suspect
    Joseph> that in practice the byte string 00 00 00 (the first three
    Joseph> valid protocol bytes) would be sufficient to filter out
    Joseph> 99.99999% of all shell output.

This works for me.  Searching on the text version does not work as
well because I can actually see some program outputting that.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 31 Aug 2006 15:39:25 -0400

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 31 Aug 2006 16:44:23 -0500

> how strong the requirement is?

It's practically pointless :)

I think no change is required but don't object to the proposed change.
I'll shut up now.

Nico
--