Re: iSCSI: Text request/response spanning - security issue?

[Luben Tuikov <luben@splentec.com>]

Paul Koning wrote:
> 
> I would argue that an implementation can, and should, have its own
> protective limits no matter what the standard may have to say about
> it.

Yes and no.

Yes, since a well written implementation
should indeed check buffer limits (if they are known
beforehand).

No, because a computer program is a theorem proof;
the theorem being the specification, which is the iSCSI
draft/RFC. And if the specification is faulty, then
there is no way the program can work.

>  If a well-crafted sequence of messages crashes an implementation,
> the blame goes to the implementation, not to the standard.

Yes, but I can crash a conforming to the iSCSI spec implementation,
by sending it an extremely long "KEY=VALUE" sequence.
That is, the implementation will have to keep a state
until 0x00 is received so that it can _then_ interpret it.

> One question: are we concerned here with an individual "key=value" or
> with all of the key=value pairs in the text messages taken together?

Answer: limit ONLY a "KEY=VALUE" sequence. Either by
negotiation per assignment or global.

Reason 1: The reason is that such a sequence can span PDUs.
If it didn't, then it is limited by the PDU size.

Reason 2: Multiple "KEY=VALUE" pairs that span PDUs have NO
burden on memory because as soon as a 0x00 is received
_that_ key=value assignment is processed and the memory
where it is kept is _freed_. (something like a conveyer belt)

BUT as noted in reason 1, you support a KEY=VALUE assignment
to span multiple PDU's AND I send you one, you'll have to
``wait'' or ``keep state'' until I send you 0x00
and by that time you can run out of memory.

For a reference see char *gets(char *s) which has exactly
the same problem I'm describing here.

-- 
Luben