Subject: [netmod] data-not-unique not secure

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Aug 2008 17:10:38 -0700

Hi,

Access control is not considered at all for unique tests.
It is possible that a user issuing the <edit-config> on running,
or <commit> of the candidate, is not authorized to view some objects
which are identified in the <rpc-error> elements returned by the agent.

Depending on the actual access control system in place,
it is possible to construct attacks on the agent by
manipulating list entries which the user is allowed to
edit, and then receive the values of keys, and learn the existence
of unauthorized list entries through <error-path> and other
data within the <rpc-error>, returned for the 'data-not-unique'
error in section E.1.

Is this a problem or not?

Note that the 'must-stmt' is allowed in many more places than
the 'unique-stmt', N entries per node, and there is no data
at all returned in the 'data-restriction-violation' error in E.4.

IMO, the error in E.1 should work the same way.
No data. no security leak.  The manager
has the YANG modules.  It can do a <get-config>
and run the unique-tests itself to find out
what went wrong.  (If that solution is good enough
for 'must-stmt', it is good enough for 'unique-stmt').

Andy

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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 29 Aug 2008 09:28:17 +0200 (CEST)

> Access control is not considered at all for unique tests.

[...]

> No data. no security leak.

"bailing out near line 1" -  Not very helpful, but secure.

What if we specify that any instance identifiers returned in the error
MUST be checked for read access control?

Otherwise, I think we have the same problem in general.  When you do
<validate> in NETCONF, and the config is invalid, with the "no
data. no security leak." approach, the reply to <validate> should just
be "error".  Is that what we want?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 29 Aug 2008 01:13:03 -0700

> be "error".  Is that what we want?

Explain to me again why all this data is needed for
a unique-test failure, but none at all is needed
for a must-test failure?  Am I missing something?
This data is not really needed at all.

The commit or edit-config has failed.
All the access control tests have passed,
which is supposedly done in order to allow the operation
in the first place.  Access control is not a factor,
We already punted this one by saying "by some magic,
all access for the commit is granted".  By the same magic,
the error messages are secured.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 29 Aug 2008 10:32:23 +0200 (CEST)

> This data is not really needed at all.

It's needed to help the operator understand why the config is not
valid, and what can be done to resolve it.

For 'must' expressions, we can't do much more than letting the
error-path point to the node with the failing must and give an
error-app-tag.  But I expect implementations to attach more data in
the error-info part of the rpc-reply, for some of these errors.  [I
had a proposal for also defining this error-info content, but at that
time we said that it could wait.]

I'd rather put in more data in the errors, in order to help the
operator, than removing data.  Taking your logic to the extreme, why
do we specify error-app-tag and error-message at all?  We can just say
"error", and let the operator do a <get-config>, and run all
validation off-line to figure out why validation failed.

> the error messages are secured.

Are you saying that even if we do send the instance identifiers in the
unqiue-error, it is not a security problem?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 29 Aug 2008 05:58:21 -0700

> unqiue-error, it is not a security problem?

You don't need to send any data to have a security problem.

If I have access to 1 list entry (that uses the unique-stmt),
then I can simply use a trial-and-error brute force attack,
and keep setting the leaf I want to uncover to different
values.  As soon as I get back a data-not-unique error,
I know one of the entries has that value.  Further attacks
may or may not be possible from that point.

Returning all the data for the non-unique entries makes
the hackers job much much easier.  (They told us not to
do that in security school ;-)

If I have access to the <foo> subtree (out of the entire <config>
element) then whether I use candidate or running as the target,
the 'commit tests' are designed to check all the data,
even the vast subset I am not authorized to touch.
An agent needs to suppress error messages for unauthorized data,
but I doubt any actually do that.

Andy