Re: security doc - Definition of Trust

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:
>
>  
>
>       - 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.
>
>  

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.



>
> 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?
>

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:
>
>  
>
> *         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.
>

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.



> 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?
>

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 protected] - http://asomi.com/