Re: PS & Arch drafts: status and security issues

In response to this comment, 

> 	I see several threat issues.  The first is the tension between
> 	direct copy and packet authentication.  In many cases, it is not
> 	possible to authenticate a packet until the entire thing has been
> 	read.  But here, the data is being copied to a receiving buffer
> 	directly from the wire, before authentication takes place.  This
> 	is especially a challenge to a multi-threaded interface --- ATM
> 	where the cells for some packet are not consecutive, perhaps --
> 	where you might get interleaving.

Caitlin Bestler <[email protected]> writes:

    This assumes that placement of non-authenticated data into a target
    buffer represents a threat, but that is not the case.

    The contents of the buffer are logically void until completion of
    the trailing untagged message, by which time all of the packets
    have been authenticated at the transport layer.

    Authentication *above* the transport layer is unchanged. It is done
    *after* the ULP accepts delivery of the message.

    Now admittedly an application that ignores the rules and examines
    the data while its contents are still undefined is leaving itself
    open for an attack -- but that is true in general. The best
    encryption in the world is worthless if you publish your private
    key on your web site, or just leave it lying around in an
    unprotected file.

I'm not sure I would be quite so dismissive.

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.

Of course, there are a lot of assumptions behind this hypothetical
attack, and it's not clear if it's significantly worse than any
other stack-smashing attack.  But it suggests that there might
be counter-measures that the receiver could take ... for example,
if authentication fails then the buffer should be overwritten
with a "safe" pattern (say, all-zeros or something else that is
unlikely to represent executable code) rather than simply being
treated as "undefined."

I'm reasonably sure that someone will explain how this attack
is either not possible or very unlikely to create a new security
hole.  But it only took me about 30 seconds to think it up, and
I don't think of myself as very devious -- I'm often surprised
by the creativity of malicious hackers, and I think we need to
be thinking about this problem from their point of view, not 
from the point of view of what the spec expects the application
to do.

    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?

-Jeff