Subject: Re: [Netconf] Breakout room Diamond 1 - for EOM discussion today, 5pm Beijing time.

From: "Andy Bierman" <[email-masked]>
Date: Fri, 12 Nov 2010 14:24:19 +0800

Hi,

We are implementing netconf, not XML parsers that send each other messages.  A conformant 4842bis implementation is not allowed to send this string, so only a buggy client has this problem.

If we used 0x4 instead of the current eom then a buggy client can cause this exact problem in the server.

IMO, we are debating meaningless conjecture when we talk about which bugs are going to happen in the future.  

4742bis says what a client must do.
A client that implements the spec correctly doesn't have a problem.

Andy 

----- Reply message -----
From: "Ladislav Lhotka" <[email-masked]>
Date: Fri, Nov 12, 2010 13:00
Subject: [Netconf] Breakout room Diamond 1 - for EOM discussion today, 5pm Beijing time.
To: "Andy Bierman" <[email-masked]>
Cc: "Bert (IETF) Wijnen" <[email-masked]>, <[email-masked]>

On Čt, 2010-11-11 at 17:58 -0800, Andy Bierman wrote:
> On 11/11/2010 05:34 PM, Ladislav Lhotka wrote:
> > On Čt, 2010-11-11 at 15:53 -0800, Andy Bierman wrote:
> >
> >> Here are the issues that I have with this entire discussion:
> >>
> >> What are we fixing? what problem are we trying to solve?
> >> People skip over this part as if it were irrelevant, but to me
> >> the solutions are irrelevant if we cannot agree on the problem.
> >
> > I believe what we are fixing is a security hole.
> >
> >>
> >> It seems the problem is that XML allows ]]>]]>  to appear in
> >> an XML document, but NETCONF does not allow it.  The current
> >> 4742bis text says so.
> >
> > This is also quite unsystematic. A transport layer spec should not state
> > rules concerning message contents. Does it mean that I can use "]]>]]>"
> > when using TLS but not when using SSH?
> >
> > On a practical side, XML well-formedness can be checked with
> > off-the-shelf tools while the search for "]]>]]>" requires a special
> > implementation.
> >
> 
> Let's do a little reality check...
> We are not really concerned with XML attributes in NETCONF content
> because we are standardizing on YANG, and YANG does not allow them.
> There is only 1 place in the entire protocol where a client could
> possibly provide an XML attribute and that is in the <rpc> element.
> 
> There are no implementations at all that allow the user to specify
> XML attributes to add to <rpc> and I doubt this will ever happen because
> it serves no use case at all.  This NETCONF feature is for the client
> implementation.  I do not know of any application implementation that
> actually uses it at all, let alone provides a user API to set these attributes.

For a cracker, the easiest way is to try to smuggle an XML comment like
this to _any_ place of the XML document:

<!-- ]]>]]><rpc message-id="101" xmlns="...">...</rpc> -->

This is a perfectly valid XML, any parser will be happy to completely
ignore the comment. If this is not a huge security hole, then I don't
know what else is.

Lada 

> 
> Therefore it seems quite reasonable to keep the current 4742bis text
> and require a client to make sure ]]>]]> is not sent inside a NETCONF message.
> In theory XML allows in in a PI or XML attribute.  In reality, NETCONF
> does not use these XML features so a client should not ever need to send them.
> 
> 
> Andy
> 
> > Lada
> >
> >>
> >> So a real actual debatable issue is whether or not it is reasonable
> >> to require a NETCONF client application to make sure this sequence
> >> is not sent in an XML document.  If so, then the current 4742bis solution
> >> is fine and no changes are needed to anything.
> >>
> >> If it is not reasonable to require a client to check for ]]>]]>
> >> and escape it (e.g., change>  to&gt;), then a new framing mechanism
> >> is needed.
> >>
> >> In that case, a new framing mechanism is needed.
> >> If any character sequence whatsoever is used within the content,
> >> then the client must implement it correctly.
> >> IMO, it is a purist's argument to say that a client must not
> >> need to check for otherwise legal XML.  The client must escape
> >> the magic marker no matter what it is.  Solutions which require
> >> the client to send some exact XML fragment are flawed, because
> >> from a purist POV we cannot restrict valid XML in any way at all.
> >> A magic PI or comment cannot be used because it is legal for
> >> a 4741 client to send them, and if a 4741bis server misinterprets
> >> the sequence, the wrong NETCONF version will be used.
> >>
> >> Way down the list, after a new framing mechanism is picked, there is the
> >> issue of coexistence with old servers.  Then a new debatable issue exists,
> >> on how to do this.  One approach is to use a new subsystem and another
> >> is to use a magic PI or XML comment before the<hello>.  The base:1.1
> >> capability in the<hello>  could also be used.  Using the same subsystem
> >> means the old message framing is used for the first message, but maybe
> >> not used after that, depending on if both sides agree to use base:1.1 or not.
> >>
> >> Using the old framing at all in the protocol means a hacker can still
> >> inject messages just the same as now, except only for the first message,
> >> instead of any message.
> >>
> >> So there is a debate whether using a new subsystem (e.g. netconf-eom)
> >> is too much burden or not.  IMO, this is the safest and cleanest way
> >> to support both 4741 and 4741bis servers.  A new client would first try
> >> netconf-eom and then netconf if that did not work.  Over time, there
> >> will likely be only netconf-eom servers so the client will never need
> >> to try the old subsystem.
> >>
> >> Using 2 subsystems keeps the problem localized to the transport layer code.
> >> There are no new special interactions between the message and transport code needed.
> >> There are no buffering requirements for the transport, waiting to be told
> >> which transport framing mechanism has been negotiated in the operations layer.
> >> It is also very clear to implementors what to do because SSH is being used as designed.
> >> Using a magic PI or comment would be a hack that people who know SSH may not expect.
> >>
> >>
> >> Andy
> >>
> >> _______________________________________________
> >> Netconf mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/netconf
> >
> 

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Fri, 12 Nov 2010 08:24:03 -0500

>A client that implements the spec correctly doesn't have a problem.

s/4742bis/The new 4742bis/
s/the spec/the new spec/

So the question is if we are fixing the problem via a new spec, why
not fix it in a simpler, more straight-forward way that doesn't
involve making valid content illegal and that allows us to deprecate
this annoying multi-byte EOM marker?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 12 Nov 2010 20:05:15 -0800

> s/4742bis/The new 4742bis/

actually the 4742bis draft is technically done and off the WG plate.

> this annoying multi-byte EOM marker?

So the problem is that the EOM has too many bytes?
The fact that we were told to use the wrong char sequence for 4741
is annoying.  Too bad Lada wasn't on the XML Directorate then.  Oh well.
If only we had 0x4 from the start.

All the solutions suck, so we are trying to pick the least suckiest solution.

IMO the least suckiest is to force NETCONF peers to encode ]]>]]>
in some other way if it is part of the message content.
For example, the yuma code will always generate &gt; instead of >,
even for attribute content.  No user data can make it into a comment.
No PIs are ever used at all.  Problem solved.

Libxml2 takes care of character entity replacement at the receiving end.
The user data at both ends contains >, but the bytes on the wire do not.

I really want to avoid a huge non-backward compatible change for 1.1.

I have a long list of features I want to add to NETCONF.
If we are making this a major release, then we should rewrite the charter.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 12 Nov 2010 21:10:48 -0800

On 11/12/2010 08:05 PM, Andy Bierman wrote:

I take back what I said about wish 0x4 was here from the start.

 From the data-injection-attack POV, 0x4, or any magic sequence in the data,
are all equally bad.

   * It doesn't really matter whatsoever if the magic pattern is not allowed
     to appear in valid XML.
   * The magic pattern will never will appear in any XML document on a server
     that implements SSH message-chopping correctly. That's the point Wes
     has been making over and over.
   * If the client does not check for the magic pattern and escape it,
     then the data injection attack can succeed.
     It does not matter what the magic pattern is.
   * Clients that don't check the user data on input are never going to check it.
   * No real client sends data through a validating parser.  They just serialize
     data structures, writing directly to the session.

Phil, why don't you want to do real framing now?
That seems the the most difficult to implement but also the most difficult to hack.
It seems like if we were solving the data injection attack problem then
using tags outside of the XML stream seems the best choice.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Sun, 14 Nov 2010 21:27:58 -0500

>Phil, why don't you want to do real framing now?

Because the WG does not seem to have an interest in it, which
is sad.

>using tags outside of the XML stream seems the best choice.

Amen.

Thanks,
 Phil