Re: Ever onward

[Wes Hardaker <wjhns1@hardakers.net>]

>>>>> On Fri, 30 Jan 2004 02:58:48 -0500, Phil Shafer <phil@juniper.net> said:

Phil> 9.1: DoS attack using global <lock>
Phil> Concensus: not realistic scenario

If you want a scenario:

1) attacker gains access to a poorly kept up machine with netconf
   support and steals a netconf username/password which has limited
   configuration privileges elsewhere but does have locking ability.
   This could be anything from a poorly updated router to a simple
   printer, etc.  Or, social engineering attacks (I've always hated
   that term) is trivial these days (I've called NOCs and had someone
   I didn't know give me a password just because I said I was either
   myself or my boss.  They failed the test).

2) attacker opens a connection to the 10,000 deployed devices in the
   network and locks the configuration on all these devices.  The
   attack script would auto-detect a broken connection and reconnect asap.

3) administrator painfully tries to fix all those devices.  Notes:
   can't be fixed without a specific tool or protocol to steal the
   lock back and delete/modify the compromised user.

4) If you believe you can beat the race condition that has been
   discussed, you should note that the attack could also involve a
   DDoS attack against the management station, network, or router in
   front of same.

The fundamental problem here is that you're mixing global operations
and isolated operations.  You want to provide fine-grained access for
some commands and not for others all of which affect the same objects,
which is fundamentally a poor security design.  Heck, it would be
better if you declared the protocol "administrator only" and didn't do
any access control.  A less usable protocol, but at least more
consistent.

I'm confused why disallowing locks to affect non-accessible objects is
a problem?

Currently to access a object is granted using psedo-code:

  int global_lock_owner;
  int current_user;

  if ((global_lock_owner == 0 || global_lock_owner == current_user) &&
      write_access_allowed(object, current_user))
    do_it();

It's not significantly harder to check the ownership of the lock
against the access for that object:

  if ((global_lock_owner == 0 || global_lock_owner == current_user ||
      !write_access_allowed(object, global_lock_owner)) &&
      write_access_allowed(object, current_user))
    do_it();

One extra call to the access routines fix this problem without
removing the need for a more complex lock than a global lock, but make
it more secure.  IE, only allow a user to lock objects they have write
access too and problem solved and it's not a huge burden at all (It's
a double call to the access function which will be slightly slower but
netconf isn't designed for a rapidly-used protocol now anyway).

Phil> 9.3.1: Authorization control for protocol operation based access
Phil> Concensus: follow permissions/mechanisms for CLI users

Phil> 9.3.2: Authorization control for High-level RPC calls
Phil> Concensus: follow permissions/mechanisms for CLI users

Note that this will make it hard to standardize on a mechanism by
which access control is configured in the future.  Devices likely have
incompatible access control models on how this is done these days.
Locking to the current CLI now means that you'll have to figure out
how to fix this in a inter-operable way in the future without breaking
backwards compatibility or punt in the future and always do it in a
implementation dependent way in the future and sacrifice
interoperability with respect to acc

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>