RE: PS & Arch drafts: status and security issues

At 02:21 PM 2/21/2004 -0500, [email protected] wrote:
> > >>> 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.
> > >>
> > >> 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.
> > >
> > > Unfortunately, that's not the comparison that the AD who wrote the
> > > original comment is concerned with.  The comparison of interest
> > > is whether RDDP introduces additional security issues by comparison
> > > to a protocol stack that does no direct placement.  Jeff's outlined
> > > a scenario in which a corrupted buffer that the ULP would not
> > > ordinarily look at could be used as part of an attack on the ULP.
> > >
> > > The first-order response to this threat should be a
> > > recommendation to use IPsec and run the packet authentication/
> > > integrity check *before* placement when this threat is a concern.
> > > The "*before*" is a good idea anyhow, as the IPsec check also covers
> > > the placement data.  Beyond this, Jeff's suggestion to overwrite
> > > placed data that has failed this sort of check seems reasonable,
> > > and the possible need to do that overwrite can be added to the
> > > discussion we already need on why TLS and in-order security
> > > mechanisms like may not be good fits to RDDP.
> > >
> >
> > DDP works on packets presented to it by the LLP. They can be
> > presented out-of-order, but they have to have passed LLP
> > validation.
> >
> > So LLP or lower security/authentication is transparent to DDP.
> > Admittedly serial methods aren't likely to present packets to
> > DDP out-of-order. If they are using host memory for their own
> > packet processing then the benefits of RDMA will be minimized.
> > But many "before" packet authentication/integrity checks can
> > essentially be performed as though they were in the network
> > rather than on the host itself.
>
>That looks like violent agreement - the best thing to do if injection
>of invalid traffic is a concern is to arrange the security functionality
>so that invalid data is rejected prior to placement.
>
> > Voiding invalid data post RDMAP/DDP is exactly that, a post
> > RDMAP/DDP step. But ultimately it is the same issue for any
> > application that applies application layer security/authentication
> > above the transport layer.
>
>There's one very important difference.  In error cases, RDMAP/DDP
>will place data in buffers that are never successfully received
>for ULP processing, including application security/authentication;

RDMA/DDP may place data into buffers which are completed in error upon a 
problem being detected.  The associated ULP / middleware knows that on 
error the buffers are in an indeterminate state and thus should not be 
trusted in terms of their contents.  Implementations may scrub (e.g. zero 
out) the buffers, release the buffers, etc. and see no ill effects.

>a vanilla (e.g., sockets) interface does not do that - in the error case, 
>the unreceived data is in unpredictable system buffers that the system 
>cleans up as a routine matter.

It is somewhat a function of where processing occurs as this can vary by 
implementation.  For example, in a user-space or embedded environment 
network stack implementation, the buffers may be ULP buffers and thus 
placement may have occurred.  The clean-up process / exposure would be the 
same as for RDMA/DDP.  I recall several network stack implementations (e.g. 
Solaris fastbufs from a few years back) that allowed application buffers to 
be posted to a NIC and thus making them subject to this same concern as for 
RDMA/DDP.

For a traditional OS kernel network stack implementation, the ULP may or 
may not see the data depending upon where it sits relative to the network 
stack such as directly on top of the LLP or on top of a sockets 
interface.  I agree that in many OS, the kernel buffers which are used for 
intermediate receive buffers provides a method to isolate any erroneous 
buffers from the application if a copy operation is performed as detection 
of an error / security violation may result in these buffers being scrubbed 
/ freed prior to the copy operation which is a fairly standard operating 
procedure.

>RDMAP/DDP has more junk that may have to be cleaned up in error cases, and 
>this will need to be noted as a potential security concern.

I do not disagree that a warning should be provided but it isn't unique to 
RDMA/DDP as this problem exists with existing network stacks / usage models.


> > But the bottom line is that incorrect STags, MOs or TOs do NOT
> > pose a security problem -- whether they result from packet
> > injection, undetected packet corruption, a peer software
> > bug or a peer with less than honorable intent.
> >
> > All local memory access is enabled by the ULP using the local
> > interface. The STag/TO, MSN/MO can only select bytes within
> > the enabled local memory.
> >
> > Ease of packet injection is determined by the LLP, and is not
> > affected by RDMA. The ability of a peer to supply payload that
> > is not what was expected also exists with or without RDMA.
> >
> > The ULP must adjust to the fact that is not bothered with
> > the details. It does not know which bytes of the advertised
> > buffer were written in what order, but this is not a security
> > problem if the buffer is being used properly.
> >
> > The ULP can decide to trust its peer, and simplify its use
> > of the local interface resulting is some excess exposure of
> > its buffers. But they are user buffers, the negative impact
> > of their abuse can easily be evaluated on an application
> > specific basis.
> >
> > So an application that is perfectly capable of treating
> > a void buffer as a void buffer should not have to pay the
> > overhead of having their iWarp provider zeroing out voided
> > buffers.
>
>In other words, it's a ULP by ULP decision, and the possible
>security consequences of deciding whether or not to void out the
>buffers in the error cases needs to be discussed in the security
>considerations section.  I never said that this voiding out
>would need to be mandatory

I would be opposed to making this a mandatory requirement.

>  - it should suffice to have a solid discussion of the security exposure 
> here (and there is a security
>exposure based on the fact that placement can occur without the ULP being 
>told about it in error cases), and ways to deal with it, with voiding out 
>of placed but unreceived data as a possible means of doing so.
>
>OTOH, announcing that this does "NOT pose a security problem" is an 
>invitation to a lengthy discussion with the Security ADs, who happen to be 
>correct that there is a potential security issue here that needs attention 
>in the security considerations section of the architecture draft (and also 
>in the security draft).

Mike