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