RE: RDDP-enabled iSCSI "hole"

David,

Why are you assuming that there is a separate iSCSI CRC above and
beyond the RDDP CRC? I assume that use of iSER implies use of
RDDP CRC. And in this case, the hole is pretty big, whether the
STags are single-shot or not.

Somesh

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On Behalf Of
> [email protected]
> Sent: Sunday, June 06, 2004 1:41 PM
> To: [email protected]; [email protected]
> Subject: [rddp] RDDP-enabled iSCSI "hole"
> 
> 
> Uri,
> 
> > I'd like to chime in on this important discussion. I'm sorry,
> > but I do fail to see the "new" security hole. 
> 
> Here's a scenario where long-lived RDDP STags cause a potential
> iSCSI security "hole" that can't occur with single-shot STags or
> in the absence of RDDP.  I'm going one step beyond Somesh and
> assuming that the iSCSI data CRC is still being used with RDDP
> (in contrast to Somesh's assumption that the RDDP CRC(s)
> replace(s) the iSCSI data CRC - that assumption opens the "hole"
> wider because the RDDP CRC is checked earlier):
> 
> (1) An STag is used to transfer data for an iSCSI write.
> 	The STag is left valid after the data is transfer so
> 	that the initiator and target can reuse this buffer
> 	and its STag for the next write (a fairly obvious and
> 	desirable optimization).
> (2) The iSCSI target checks the received data against the
> 	iSCSI CRC.  The check succeeds, so the target code
> 	requests a local disk write operation from the buffer
> 	that is still exposed via the STag
> (3) Before the write operation takes place, a TCP packet from
> 	the MITM attacker (e.g., connection hijacker) shows up
> 	and uses the STag to overwrite part of the write buffer.
> 
> At this point, there is corrupt data headed for the disk.  In
> the absence of long-lived STags, the TCP packet at step (3)
> gets rejected by RDDP.  In the absence of RDDP, that TCP packet
> gets through, but won't corrupt the iSCSI write data.  Hence
> RDDP's long-lived STags have opened up a new security problem.
> 
> This problem appears to be generic to any reuse of a write
> buffer and its associated STag.  If an application protocol
> uses RDDP to transfer data that is actually interpreted by 
> the application protocol, there are versions of this attack
> that target protocol functionality if the implementation
> contains code that assumes the contents of the receive
> buffer don't change.
> 
> 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 protected]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On 
> > Behalf Of Uri Elzur
> > Sent: Friday, June 04, 2004 9:56 PM
> > To: Somesh Gupta; [email protected]
> > Subject: RE: [rddp] IPsec and RDDP as a transport
> > 
> > 
> > Somesh
> > 
> > If a packet is hijacked, what will prevent the CRC match??!! 
> > So why will
> > the iSCSI over TCP data not be accepted? CRC has no cryptographic
> > value...
> > 
> > Uri
> > 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On 
> > Behalf Of
> > Somesh Gupta
> > Sent: Friday, June 04, 2004 6:28 PM
> > To: [email protected]
> > Subject: RE: [rddp] IPsec and RDDP as a transport
> > 
> > 
> > It seems that for iSCSI specifically, RDMA writes icrease the
> > possibility of data corruption, even with 'one-shot' STags. Consider
> > iSCSI over TCP, with header and data CRC. If a random TCP 
> > packet is used
> > to attack the connection, and the packet is accepted (large windows
> > etc), the CRC checks will fail and the problem detected before a
> > corruption occurs.
> > 
> > Now consider iSCSI using iSER over RDDP. iSCSI depends on RDDP for CRC
> > checks. An attack on the connection (out of order RDMA writes) could
> > place data in the write buffers and if this happens, the attack will
> > never be detected.
> > 
> > Maybe this problem is iSCSI specific only.
> > 
> > Somesh
> 
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rddp