Subject: RE: [rddp] security doc - Definition of Trust

From: "Jim Pinkerton" <[email-masked]>
Date: Mon, 21 Jul 2003 14:23:58 -0700

I see at least two issues brought up in this email:

1) I'm having problems grappling with the various levels of grayness on
what the intent of the remote peer is. I think there are many reasons
why a particular attack can occur, including:

      - bug in the implementation

      - lax coding in an application which runs in kernel space 

            which opens up security holes for other applications

      - unintentional attacks due to performance optimizations

      - unintentional attacks due to whatever...

      - intentional attacks

Personally, I don't see it worthwhile to put a lot of text throughout
the document saying all the reasons why a particular attack can occur -
the most important thing is that it did occur. How it occurred is
presumably highly implementation dependent, and thus not necessarily
appropriate for a security draft of a wire protocol.

In re-reading the security draft though, I realized I don't have this
type of statement in the introduction where Trust and Untrusted is
defined. Would it help if this was added?

Caitlin, could you make a suggestion on recommended text that I could
add to the paragraph below on "Untrusted" to point this out?

2) Adding of MUST and SHOULD text to the document. To date I've tried to
stay away from MUST and SHOULD normative text, and instead point out
issues, with recommended solutions. There is exactly one MUST statement
in the document:

*          All Non-Privileged Application interactions with the RNIC
Engine that could affect other applications MUST be done using the
Privileged Resource Manager as a proxy.

The rest of the document takes the approach that if you want this type
of a Trust Model, and care about this specific attack, it is RECOMMENDED
that you do this. I'm not clear on how to map your issues at the end of
the email below to this approach, or are you advocating a different
approach in the document? If so, could you outline it?

Jim

 

-----Original Message-----
From: Caitlin Bester [mailto:[email-masked]] 
Sent: Monday, July 21, 2003 11:11 AM
To: Jim Pinkerton
Cc: [email-masked]
Subject: Re: [rddp] security doc - Definition of Trust

On Monday, July 21, 2003, at 12:44 PM, Jim Pinkerton wrote:

> One of the issues that has come up on the reflector is that the 

> definition of Trust should be changed to "Partial Trust", with an 

> appropriate change to the definition. The existing draft defines trust

> as:

> Trust - When one party depends upon the other party to not subvert the

> goals of the protocols, e.g., it will not attempt to perform the 

> following attacks: spoofing, repudiation, information disclosure, 

> denial of service, or elevation of privilege.

> An Untrusted peer is a party that may (or may not) attempt to perform 

> one or more of the above attacks. A partially trusted peer (either the

> Local Peer or Remote Peer) may be trusted to not attempt to perform 

> some subset of the above attacks, but not trusted to perform a 

> different subset.

> Possible new definition (feedback/wordsmithing appreciated - I want 

> general agreement on this before I go through the spec):

> Partial Trust - When one party depends upon the other party to not 

> attempt to perform a specific attack or set of attacks. A partially 

> trusted peer (either the Local Peer or Remote Peer) may be trusted to 

> not attempt to perform any subset of the specific list of attacks. 

> However, there is no guarantee that the Peer won't try to perform a 

> different set of attacks.

> An Untrusted peer is a party that may (or may not) attempt to perform 

> one or more of the listed set of attacks.

> Jim

 

I believe there needs to be a distinction between "trust not to launch 

an explicit attack" and "trust to conform to the ULP".

To a large degree, the intent of the peer is irrelevant. The question 

is really relates to how paranoid must an application

be under what circumstances.

For example, while it will always be possible for the ULP to tailor 

tagged buffer exposure to *exactly* the degree required,

a local ULP could easily find this inconvenient to do. If may elect to 

enable an STag covering a set of buffers, and rely

upon its peer to only write to the portion that was enabled per the ULP.

However, it should not do so if it imperils any other process or any 

other party by doing so.

If you use a shared buffer pool for untagged messages, and the scope of 

that sharing encompasses DDP Streams with

multiple clients, then your trust of Client A should not place your 

interactions with Client B at risk (I would almost be

tempted to say MUST NOT).

Here is a very specific example where Client A may not be "attacking". 

Client A may merely be a bit over-eager and

sending the nTh request before receving the n-mth response and thereby 

has more than m requests pending.

These "cheating clients" have no intention of bringing the server down, 

but if there are enough of them they will

drain the shared buffer pool and eventually force another client's 

stream to be terminated (or possibly only

undergo a false drop). At that point they have damaged the other 

client, but there was never an intention to "attack".

Now just to be safe, it is probably worth stating that there are a set 

of known "attacks" which are automatically

considered to be "non-compliant" with the parent ULP. At least by 

default, the ULP could be something like

a hacker contest where you are *encouraged* to forge your address. But 

otherwise I think we are quite

safe stating that the type of attacks explicitly listed so far are 

presumed to be non-compliant with the ULP.

But the ultimate goal should be to make it clear that:

-- The local interface MUST provide tools to allow the ULP to protect 

itself.

-- The local ULP  MUST use these tools to enable its peer to perform as 

specified under the Upper Layer Protocol,

-- The local ULP MAY enable more access than what is required to 

simplify its use of the local interface, but

     SHOULD NOT do so if it imperils any other process or any other 

sessions.

But the need to protect yourself from stray bullets exists whether the 

shooter was aiming for you or not.

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 21 Jul 2003 17:46:04 -0500

On Monday, July 21, 2003, at 04:23 PM, Jim Pinkerton wrote:

> 1) I'm having problems grappling with the various levels of grayness 
> on what the intent of the remote peer is. I think there are many 
> reasons why a particular attack can occur, including:
>
>  
>
> the document saying all the reasons why a particular attack can occur 
> - the most important thing is that it did occur. How it occurred is 

I prefer to simply describe such behavior by the peer as 
"non-compliant". It places the emphasis on the fact
that the buffer access varies from what the Upper Layer Protocol 
specified, without dwelling on why or how
it is varying.

It also places the burden on the local ULP. If you choose to enable one 
giant STag, and then simply
advertise three buffers within it, you need to be aware that you are 
trusting your peer to be ULP-compliant.
There can be major advantages to granting such trust, such as 
simplicity of coding. But you need to determine
what you have placed at risk.

I believe we can safely state that there are two cases where the local 
ULP SHOULD NOT do this (or at least
that it is really heavily recommended that they do not):

-- Exposure to resources that do not belong to the local ULP.
-- Exposure of resources that other clients / sessions rely upon.

The latter is more subtle, it is not necessarily resources that can be 
accessed on other DDP Stream.
The local client could have multiple connections to the *same* remote 
partner (especially if they still
haven't discovered SCTP and insist on duplicating its features using 
TCP). Or the remote partner may
be expressed as members of a cluster. In either case the DDP Streams 
that are being placed "at risk"
are all supporting the same remote entity. An application should feel 
free to determine how much
double-checking it wants to do against remote entity violations as part 
of being robust. Being robust
in the face peer errors is certainly commendable, but it is not 
something that should be mandated or
even lobbied for. That is strictly a decision for each application to 
determine how robust it will be.

But once you allow resource sharing across DDP Streams that support 
*different* remote entities, you
are leaving your peers subject to an indirect Denial of Service attack. 
That is a totally different issue.

> add to the paragraph below on "Untrusted" to point this out?

An "untrusted" peer is any that you do not want to rely upon to be ULP 
compliant.

A "trusted" peer is one that you do rely upon to be ULP compliant, even 
if the only reason for doing so is
that you believe your handling of that peer is sufficiently "walled 
off" that the scope of potential damage
is deemed acceptable. That is, the peer can only shoot themselves in 
the foot.

>
> 2) Adding of MUST and SHOULD text to the document. To date I’ve tried 
> to stay away from MUST and SHOULD normative text, and instead point 
> out issues, with recommended solutions. There is exactly one MUST 
> statement in the document:
>
>  
>

I do have a recommendation here. A "Privileged Resource Manager" is a 
specific strategy. A common one, true,
but it is not universal. A more generic statement would be:

   The local interface MUST NOT allow an application to grant the RNIC 
Engine any rights or access privileges
   that it does not itself already have. Typically this will require 
certain requests to be proxied by a
   Privileged Resource Manager or other mechanism that allows the RNIC 
Engine to verify access rights.

> of a Trust Model, and care about this specific attack, it is 
> RECOMMENDED that you do this. I’m not clear on how to map your issues 
> at the end of the email below to this approach, or are you advocating 
> a different approach in the document? If so, could you outline it?
>

Ok, let's give it a try. My outline would run something like this.

1 - Enabling the RNIC Engine to place memory directly to ULP buffers 
requires privilege

	The local interface must have some mechanism by which the RNIC Engine 
verifies that its clients have
     authority to make the requests being made. This may rely upon a 
single Privileged Resource Manager
     to proxy critical authorization requests.

2 - If your peer is compliant with the Upper Layer Protocol then any 
security issues are dealt with elsewhere.

	In other words, if you're accepting text messages which you pass to a 
privileged shell for execution, your
     security problems are not an RDMAP/DDP issue.

	Except as noted for rule #1, local OS security rules are also not an 
RDMAP/DDP issue. If an OS does not
     have adequate security for non-RDMA applications then RDMAP/DDP 
will not solve any of those problems.

3 - You authorize your peer to make certain remote accesses to untagged 
and/or tagged buffers.

	How you communicate this is out-of-scope. However you must enable the 
RNIC Engine to accept all
    remote access that you authorize.

	At this point the emphasis should be on the fact that if the local ULP 
uses the local interface
    with precision that the remote peer will be incapable of doing any 
damage. An RDMA application
    can actually be less vulnerable to attack than one using the LLP 
directly.

4 - You may end up enabling more access than is ideal -- Potential 
impacts and counter-measures

     Examples of this include the time gap from the last tagged put 
until you can invalidate the STag,
     or using a overly broad STag that enables multiple advertised 
buffers.

     The potential impacts should be explained and highlighted. (The 
local ULP cannot detect excess
     or inappropriate Tagged puts unless remote access is invalidated. 
Unlike a classic buffer overrun
     attack, there would not normally be logged information allow an ex 
post facto diagnosis).

     Methods of avoiding the attack would be highlighted (use narrow 
STags that are quickly invalidated,
     check the buffer only after invalidating remote access, etc.)

	The current draft deals with these very well for tagged buffers. It is 
the discussions on untagged
     messages and shared resources that I currently have problems with.

	It is particularly in the context of impact on shared resources that 
the distinctions on  "ULP
	compliance" and "who is impacted" become critical. If my local 
interface allows me to share buffers
     and completion queues, but still allows me to impose a strict limit 
on the number of untagged
     messages that will be accepted from my peer, then there is no 
exposure. The peer is ULP-compliant,
     or the DDP Stream is terminated.

     If I have a soft limit on untagged messages once shared resources 
are in use, then I have a
     potential vulnerability. I need a strategy to determine how much 
could be exposed to a non-compliant
     remote peer in order to ensure that there were adequate safeguards 
to prevent one faulty/attacking
     peer from adversely impacting others.

     Too much of the current outline seems to imply that you can be 
paranoid or you can be efficient,
     without really helping the application developer find their own 
optimum balance.

Caitlin Bestler - [email-masked] - http://asomi.com/

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