Re: PS & Arch drafts: status and security issues

I wrote:

> Here is a *hypothetical* attack that is (1) not dependent on
> an application programmer violating the "logically void"
> restriction, and (2) possibly made easier by the failure of
> packet authentication:
>
>     Step 1: attacker inserts packet fragments into a TCP
>     connection between host H_benign and host H_victim,
>     where the connection is using packet authentication.
>
> 	authentication in this case will fail, but
> 	perhaps not before some fragments have been
> 	placed.
>
>     Step 2: attacker somehow causes (e.g., via a buffer-overflow
>     attack that smashes a stack frame) the application
>     to execute code out of the "corrupted" buffer.
>

Caitlin Bestler <[email protected]> writes:

    Buffer overflow? That's a symptom of anonymous buffers
    defined only as streams -- which does not apply to RDMA.
    
You're thinking inside the box.  I didn't say "cause an
overflow of an RDMA buffer"; applications have many buffers,
only some of which are involved in RDMA.  Typical buffer
overflow attacks often target intermediate buffers within
the application.

So whether or not RDMA prevents overflow of network-related
buffers has nothing to do with whether an application is
vulnerable to other kinds of buffer-overflow attacks.

    However an executable image is received it should be
    ULP authenticated *before* execution. Authentication
    of executables and confining the scope of damage of
    partially trusted executables are OS issues. They
    have nothing to do with transport.
    
Nor did I say they did.  But in the typical stack-smashing
attack on an application, one could hardly argue that the
application has done everything it "should" have done; the
fact remains that they succeed all too often.

    >     In general 90% of the "security issues" related to RDMA can be
    >     summarized as "the consumer may use the local interface in a manner
    >     which exposes more memory access rights than is strictly required
    >     by the ULP."
    >
    > Right, but what if the "consumer" in this case is an application
    > that has already been partially broken into by an intruder, who
    > can then use RDMA to open a wider hole?
    
    Each and every memory byte accessible by RDMA was accessible by
    the application anyway. The ULP is merely delegating access rights
    that it already had to the RNIC.
    
I'm not sure this is true -- the question quoted in David's
original message was (in effect) whether an attacker could sneak
bytes past a packet authentication stage in a way that would not
be possible if RDMA were not used.  Whether or not the application
*should* look at such bytes is not the issue; the problem arises
when the application can be tricked into looking at them.

I remain willing to believe that the attack I hypothesized cannot
actually be made, but I don't think you have proved that because
I think you are confusing what applications should do with what
they might be caused to do.

-Jeff