Subject: Re: [Netconf] how to handle XML parse errors

From: "Andy Bierman" <[email-masked]>
Date: Tue, 17 Aug 2010 08:21:05 -0700

Hi,

IMO, the likelihood of an injection attack is more likely than a buggy manager, and that is more important.

The server may not ever know which part of the message caused a parse error.  In the libxml2 code I use, the EOF error will occur looking for a missing end tag.  The server cannot report the exact error.

Andy

----- Reply message -----
From: "Wes Hardaker" <[email-masked]>
Date: Tue, Aug 17, 2010 07:38
Subject: [Netconf] how to handle XML parse errors
To: "Kent Watsen" <[email-masked]>
Cc: "Wes Hardaker" <[email-masked]>, "Andy Bierman" <[email-masked]>, "netconf\@ietf.org" <[email-masked]>

>>>>> On Mon, 16 Aug 2010 13:12:01 -0700, Kent Watsen <[email-masked]> said:

KW> I'm wondering if this is an academic exercise or if there is an
KW> actual problem being solved here.

The issues are operational ("pipelining" as Juergen labeled it) and
security related.

The security related issue is just to protect the agent (where the
important data is stored) from badly coded managers.

The netconf agent should always be what we're trying to protect against
damage, since that's where all the important config is.  By mandating
that agent's "continue processing whenever possible" seems to me like a
bad decision that just leads to errors.

SSH (and other protocols) don't provide proper message framing.  So the
RFC inserts a magic ]]>]]> bullet that can be used to detect the "start
of the next message" so that if the current one can't be parsed you just
skip to the next.  That seems nice until you realize how many operators
are going to write scripts out there for use with netconf.  I'm *sure*
there will be ones written that fail to account for tricky user-input.
I'm sure of it because it's happened repeatedly for decades.

I don't see the goal in making it easier for them while at the same time
making coding the agent harder.  If the manager sends a bad management
request, why *should* the agent resources be used to try and figure out
where in the parsing stream the problem might be.  I do agree that
having the agent return a "error message" before closing the stream
sounds like an excellent idea.  But I don't see the benefit in wasting
the agent's resources trying to recover from a parser error.  Let the
management station figure it out.

In the SSH case (and now TLS I believe), injection attacks become very
very powerful for any management operation that doesn't very carefully
check it's input.

  #!/bin/csh
  echo "please enter your desired Account Name:"
  set loginname=$<

  echo "please enter your Full Name:"
  set name=$<

  cat << EOF | netconf-client remotehost.example.com
  <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <edit-config>
      <target> <running/> </target>
      <config>
        <top xmlns="http://example.com/schema/1.2/config">
          <user>
            <login>$loginname</login>
            <fullname>$name</fullname>
          </user>
        </top>
      </config>
    </edit-config>
  </rpc>

The above works great if the user is nice.  I'd even bet that most
people *would* check the $loginname field, since that's an obvious place
where bad data would matter.  But I'd bet that many operators will fail
to check the $name field, because why would it matter?  A name can
contain just about anything.  It works less great if the user types in a
fullname of

  ]]>]]>
  <rpc ...><edit-config>...
  <change-password login="root">newsecret</change-password>
  ...

Andy's right, it's still possible to "maybe" complete the XML anyway if
that input isn't checked.  But it takes a lot more work trying to
"guess" what the end of the XML looks like when you can't see the stream
itself to figure out how the management app is encoding the request over
an encrypted stream.  On the other-hand, the existence of the ']]>]]>'
identifier mean the SSH and TLS streams make it very very easy to inject
bad data into a message and immediately start into the next message
controlled by the attacker.  No guessing required.

Closing the session will fix this.
Closing the session will make pipelining actually safer to use as well.

Win-win.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 18 Aug 2010 08:04:53 -0700

>>>>> On Tue, 17 Aug 2010 08:21:05 -0700, "Andy Bierman" <[email-masked]> said:

AB> The server may not ever know which part of the message caused a
AB> parse error.  In the libxml2 code I use, the EOF error will occur
AB> looking for a missing end tag.  The server cannot report the exact
AB> error.

I didn't mean that we should report an exact error; sorry if I misled
you.  I was actually thinking a generic "parseError" type error (with
more detail *if* possible).
-- 
Wes Hardaker
Cobham Analytic Solutions