Subject: [rddp] PS & Arch drafts: status and security issues

From: [email-masked]
Date: Thu, 19 Feb 2004 15:51:31 -0500

I have news to report ...

The IESG has been reviewing the RDDP Problem Statement and Architecture
drafts.  The current draft status can be found in the IETF Draft Tracker at
	https://datatracker.ietf.org/public/pidtracker.cgi
Enter rddp in the WG Acronym: field and hit the SEARCH button.

New versions of both drafts are going to be needed, mostly to deal with
editorial issues, but some security issues have arisen in the Architecture
draft that I'm forwarding so that they can be discussed in the context
of the security draft on the list and in Seoul:

	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.

The risk here is that if one does placement of fragments and then runs
the (cryptographic) integrity check and the check fails, the application
has a corrupted buffer.  In particular, applications that are coded to a
sockets paradigm can get corrupted memory that was never part of any
successful receive with RDDP - that can't happen with plain sockets.

	More generally, authorization for access to storage has to be
	dependent on the connection as well as the steering tag.  Otherwise,
	you introduce new vulnerabilities.  This is especially problematic
	given that receive buffers may (according to the document) be used
	for data from a different socket.

Probably just needs some clarifying text, as I believe this was always
intended.

	Aside: I think that many of these issues, as well as the multiple
	receiver problem (and I do not accept the argument that requiring
	many different clients to use the same address is in any way
	comparable to any existing problem in that space), would go away
	if the steering tag sent over the wire to the receiver were not
	just opaque, but by intent a random 64- or 128-bit tag to a local
	buffer descriptor.  That permits easy local revocation of
	capabilities, as well as a defense against remote contamination
	attempts if the value were communicated previously over an
	encrypted channel.

Also, if the STag values generated by an implementation are hard to
predict, traffic injection by an adversary becomes more difficult.

	The use of TLS (as discussed briefly in the security considerations)
	or any other protocol that provides authentication will not fit well
	into the proposed architecture.  The integrity check cannot be
performed
	until the entire packet (or record in the case of TLS) is available
in
	memory.  So, the data must be copied from the I/O interface to
memory,
	which may involve some reassembly, before the integrity check can be
	performed. This issue should be discussed in the security
considerations.

This is the same issue as the first one, and suitable discussion should
suffice.  The bigger mismatch between TLS and RDDP is that TLS wants to
run in-order whereas RDDP wants to enable out-of-order placement.  The
combination could require a significant amount of data to be placed
before TLS can be run over it to determine that it's all junk.

NOTE: While it's ok to start working on revisions to the architecture
and problem statement drafts, this set of IESG comments is NOT COMPLETE.
When I have a complete set of comments available, I'll communicate the
comments and guidance on what to do about them to the draft authors.
Anything with technical impact will be cc:'d to the list.

Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

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

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 20 Feb 2004 13:59:41 -0600

> 	where you might get interleaving.

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.

> 	for data from a different socket.

The spec makes it clear that the ULP is in control of enabling steering
tags for specific connections. Short of drafting a "local interface
requirements" document I don't see what else can be done.

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

But I believe that all of the local interfaces that have been discussed
or proposed do a fine job of closely matching the security needs of most
applications. (I still have problems with draft-hilland's lack of 
support
for multi-connection sessions, but the overwhelming majority of 
applications
use on a single active connection per session).

> predict, traffic injection by an adversary becomes more difficult.

If the STag has cryptographic value it will be too large for efficiency.

A statement could be added that STags SHOULD be chosen so as to minimize
the risk of bit-errors changing one valid STag into another valid STag.
But there is no way to make that a "MUST" -- how would you know how an
STag you have been given compares with other STags given to other 
clients?

---

From: Jeffrey Mogul <[email-masked]>
Date: Fri, 20 Feb 2004 15:37:48 -0800

In response to this comment, 

> 	where you might get interleaving.

Caitlin Bestler <[email-masked]> writes:

    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

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 20 Feb 2004 18:50:09 -0600

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

> unlikely to represent executable code) rather than simply being

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.

> 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-masked] - http://asomi.com/
http://asomi.com/CaitlinBestlerPublicPgpKey.html

---

From: Jeffrey Mogul <[email-masked]>
Date: Fri, 20 Feb 2004 18:08:22 -0800

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.

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.

    
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

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 20 Feb 2004 20:22:13 -0600

> when the application can be tricked into looking at them.

A given byte in user memory space is either exposed for read
and/or write or it is not. The ULP validity of the packet
that takes advantage of that enabled access is irrelevant.

Developing packet steering logic for each ULP creates *more*
of a vulnerability because there are more algorithms that can
be fooled.

RDMA standardizes the unpacking process, making it easier
to validate. But there is nothing in the RDMAP or DDP headers
that "authorizes" access to memory, it merely *requests*
access to memory. The authorization came from the local
ULP, and cannot exceed the authority that the local ULP
was already in possession of.

And yes, the local interface could be compromised, leading
to an RNIC making unauthorized access to local memory. But
that is true of *any* DMA-enabled device on virtually any
local system bus.

By standardizing payload placement, RDMA can reduce the
temptation to create multiple application specific solutions
that must be promoted to the kernel for efficiency. Providing
a mechanism for efficient handling of incoming data even for
user mode applications, RDMA should decrease the temptation
of "opening up" the kernel for new applications.