Re: PS & Arch drafts: status and security issues

On Feb 20, 2004, at 5:37 PM, Jeffrey Mogul wrote:

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

Buffer overflow? That's a symptom of anonymous buffers
defined only as streams -- which does not apply to RDMA.
Each placement is to a ULP authorized buffer, period.
It was authorized by enabling an STag or by posting a
receive operation. Each receive operation specifies
a maximum size. If the message is larger it does
not "overflow" anywhere, it is discarded as an invalid
packet and the connection/stream is torn down.

Your peer can obviously use authorized buffers in a way
that you did not anticipate -- but that is also true
even before using RDMA.

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.

RDMA actually improves security here by eliminating
the need for system buffering. When system buffers
are involved there is a greater risk of "uninitialized"
data migrating from one use to another.

Unlike a conventional TCP application, with out-of-order
placement RDMA can ensure that all placements are to
unprivileged *user* memory -- greatly increasing system
integrity.


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

After delivery, the application can invalidate remote access
and then validate the received message.

But because this is a *user* buffer there is no harm in leaving
the contents there as long as the user process does not ascribe
meaning to the buffer.

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

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.

The only "security vulnerability" created is the potential that the
ULP will not properly understand what it delegated. That is why
the security document details procedures such as invalidating STags
before examining buffers when the remote peer is untrusted.


-- 
Caitlin Bestler - [email protected] - http://asomi.com/
http://asomi.com/CaitlinBestlerPublicPgpKey.html