Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]

From: Randy Presuhn <[email-masked]>
Date: Mon, 26 May 2014 09:34:08 -0700 (GMT-07:00)

Hi -

>From: Ladislav Lhotka 
>Sent: May 25, 2014 11:26 PM
>To: Randy Presuhn 
>Cc: [email-masked]
>Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
>
>
>On 26 May 2014, at 08:08, Randy Presuhn  wrote:
>
>> Hi -
>> 
>>> From: Ladislav Lhotka 
>>> Sent: May 25, 2014 9:35 PM
>>> To: Randy Presuhn , [email-masked]
>>> Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
>> ...
>>> I still don't get it. The client had received the server's
>>> hello message so he knows the complete data model. Then, in
>>> my view, not receiving a node (subtree) is semantically
>>> equivalent to receiving it with the contents of .
>> 
>> No, the two are not semantically equivalent.
>> The server's hello message reveals the sorts
>> of things that are *potentially* present.
>> It doesn't identify all the instances.
>> 
>> So, for example, the hello message might tell
>> me that a system contains "jewels".  The hello
>> message does not tell me *which* jewels might
>> be there, but "access denied" responses allow
>> me to probe to see whether some jewels named
>> "crown" or "ER" are present, even if I lack
>> the authority to examine them.
>
>If a user has no read access to a list node, say “jewel”,
>he should of course always receive the same data, no matter
>what the number of list entries is (even zero):
>
>
>  
>
>
>This gives no extra information to an attacker but still
>provides quite a useful clue to regular users.

That is true only if the attacker is allowed no access
to any jewels.  If the attacker is allowed access to
the family jewels, but not the crown jewels, then
information can leak if the responses to requests
regarding the crown jewels indicate whether they are
present, even if no access is allowed to them and
the attacker's access is limited to the family jewels.

Perhaps a more concrete example would help.  I might
wish to allow customers to configure certain aspects
of their respective dedicated, mnemonically-named
interfaces on a box serving multiple customers.
What is undesirable is that giving "access denied"
indications allows one customer to find out whether
another given customer also has an interface on the
same box.

This principle is reflected in RFC 6536:
  3.2.2. <get> and <get-config> Operations
  Data nodes to which the client does not have read access are silently
  omitted from the <rpc-reply> message. This is done to allow NETCONF
  filters for <get> and <get-config> to function properly, instead of
  causing an "access-denied" error because the filter criteria would
  otherwise include unauthorized read access to some data nodes. For
  NETCONF filtering purposes, the selection criteria is applied to the
  subset of nodes that the user is authorized to read, not the entire
  datastore.

The vulnerability is recognized in RFC 6536 as well:
  3.7.2. General Configuration Issues
  ...
  It is possible for a session with some write access (e.g., allowed to
  invoke <edit-config>), but without any access to a particular
  datastore subtree containing sensitive data, to determine the
  presence or non-presence of that data. This can be done by
  repeatedly issuing some sort of edit request (create, update, or
  delete) and possibly receiving "access-denied" errors in response.
  These "fishing" attacks can identify the presence or non-presence of
  specific sensitive data even without the "error-path" field being
  present within the <rpc-error> response.

Along with the related vulnerability:
  A data model may contain external keys (e.g., YANG leafref), which
  expose values from a different data structure. An administrator
  needs to be aware of sensitive data models that contain leafref
  nodes. This entails finding all the leafref objects that "point" at
  the sensitive data (i.e., "path-stmt" values) that implicitly or
  explicitly include the sensitive data node.

Randy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 26 May 2014 18:51:04 +0200

> another given customer also has an interface on the

I see your point, but it doesn’t apply to the ambiguity between trimming of defaults and access-control filtering.

Lada

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 26 May 2014 10:11:57 -0700

On Mon, May 26, 2014 at 9:51 AM, Ladislav Lhotka <[email-masked]> wrote:

> >> Subject: Re: [netmod] trim vs. NACM [WAS:
> draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
> >>
> >>
> >>>> Subject: Re: [netmod] trim vs. NACM [WAS:
> draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
> >>> ...
> >> If a user has no read access to a list node, say "jewel",
> I see your point, but it doesn't apply to the ambiguity between trimming
> of defaults and access-control filtering.
>
>
If the choice is between keeping the server more secure or
saving some bytes in an <rpc-reply> to the client, security is
going to win.

If the server returns nothing for a "miss" and <nacm:no-access/>
for a "hit", then an attacker can discover the existence of all the
sensitive data and all the key leaf values.

Lada

Andy