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

From: "Andy Bierman" <[email-masked]>
Date: Tue, 17 Aug 2010 13:12:19 -0700

If the hacker can see the XML then closing off the end tags correctly will be trivial.  If not, because the channel is encrypted, then it will not be so easy.

Andy

----- Reply message -----
From: "Ladislav Lhotka" <[email-masked]>
Date: Tue, Aug 17, 2010 08:41
Subject: [Netconf] how to handle XML parse errors
To: "Wes Hardaker" <[email-masked]>, "Kent Watsen" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>

On Tue, 17 Aug 2010 07:38:21 -0700, Wes Hardaker <[email-masked]> wrote:
>   #!/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>
>   ...
> 

Even if the session is terminated on non-well-formed input, it's only
little extra work for the bad guy to make it well-formed:

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

So terminating the session doesn't really close this security hole.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 17 Aug 2010 13:18:31 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Ladislav Lhotka" <[email-masked]>; "Wes Hardaker" <[email-masked]>; "Kent Watsen" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, August 17, 2010 1:12 PM
> Subject: Re: [Netconf] how to handle XML parse errors
>
> If the hacker can see the XML then closing off the end tags correctly
> will be trivial.  If not, because the channel is encrypted, then it
> will not be so easy.

No.  The attack does not depend on being able to intercept or modify
the data stream.  The detailed example showed how the failure to
exhaustively inspect USER INPUT makes the attack posisble.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 17 Aug 2010 22:43:37 +0200

On Tue, Aug 17, 2010 at 10:12:19PM +0200, Andy Bierman wrote:

> If the hacker can see the XML then closing off the end tags
> correctly will be trivial.  If not, because the channel is
> encrypted, then it will not be so easy.

Assuming that the data model is not a hidden secret (and NETCONF
itself surely isn't), it boils down to guessing the correct namespace
prefixes, no? Even brute force testing might be doable since most
people choose short prefixes. So yes, closing the session raises the
bar a bit but not for someone seriously interested.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 17 Aug 2010 22:58:14 +0200

> will be trivial.  If not, because the channel is encrypted, then it

No, it is sufficient to figure out where the user input belongs. Knowing
the data model, it is not very hard to guess that it is the <fullname>
element, given that the script asks for "Full Name".

Such simple scripts are only good for a trusted environment, otherwise a
schema-based validation on the client side is a must. Fortunately, it's
quite easy to do even in a shell script.

That said, I think that terminating the session upon receiving a
non-well-formed PDU is probably a good thing even though the security
argument is not very strong. For instance, what else could the server do
if the sequence "]]>]]>" appeared inside a valid document, i.e. in an
attribute value, PI or comment?

Lada

> So terminating the session doesn't really close this security hole.
Non-text part: text/html

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C