Re: [Crisp] xpc-00

[Andrew Newton <[e-mail]>]

On May 20, 2005, at 4:55 PM, Robert Martin-Legene wrote:

> On 20/05/05, Andrew Newton <[e-mail]> wrote:
>> Well, I don't think this is so much a security concern but rather a
>> detection of a bad client concern.
>
> Where's the limit between the two?
>
> Is security a remote root compromise? Or a simple denial of service?
> Isn't it to secure your services to make sure they can handle
> intentious bad client behaviour? (besides just malformed xml). Maybe I
> am just too paranoid.. again.

What I'm attempting to say is that if you follow the framing outlined 
by the protocol to catch poorly acting clients, you'll catch the cases 
where things like this happen instead of just buffering forever, 
overflowing stacks, etc...

>> If I understand you correctly, you are worried that a client says "I
>> have 95 octets to send" and then sends 100 more after the end of the
>> block.
>
> Not after the block. I meant within the block. The usual
> implementation of this kind would probably not start processing the
> inner contents of the "xml entity" (or what is believed to be xml)
> until the entire block is in (although one could do it word by word I
> reckon - but that is uncommon). So I'll just keep sending you chunks
> with the text "h4h4h4 y00 4r3 g3771|\|G pWn3d" without ever saying
> that it's the last chunk. How will your implementation handle that?

Well, now that you are making me strenuously think about this, there 
are four situations here... of which perhaps only three are covered:

1) Something in the way the chunk is described is wrong: well, that 
really only leaves the chunk descriptor which is one octet.  I think 
the draft talks about when to send block errors for these situations.

2) Something in the data of the chunk is wrong:  You read in the chunk 
descriptor and the chunk length.  This is three discrete octets.  The 
chunk length tells you how many octets to read next.  Once you have 
read in those bytes, you hand the data to your XML parser.  The 
complexity of this step depends on the capabilities of your XML parser, 
but there are at least 3 strategies: a) some XML parsers make this 
brain dead simple by offering a feed() function that just takes XML 
fragments (I believe Python, Perl, and libxml can do this), b) for 
parsers that are use to pulling the data from the source, a separate 
thread can be used for reading the socket and piping the data to the 
XML parser (this is the case for Java, fortunately NIO eliminates the 
potential for thread bloat here), and c) you just buffer it and hand 
the data to the parser after reading the last octet of the last chunk.  
No matter what, once the XML parser throws an exception, your server 
should send a data error (and perhaps close the session, depending on 
how nice you are).  When using strategies a or b, you can send this 
data error the moment the error occurs.  And if using strategies a or b 
and your server has already started responding with legitimate answers, 
you can still send a data error (by changing the chunk type).  If your 
server is nice and keeps the connection open, then you have to continue 
reading the block if you are using a or b.  But I don't see a point in 
being nice (lots of people can confirm this).

3) The chunk data contains XML with lots of ignorable whitespace: this 
isn't directly covered by the draft.  Technically, the ignorable 
whitespace should not cause your XML parser to reject the data, but I 
can see not wanted to accept 2000 octets of tab characters.  While a 
data error might cover that, we probably ought to define an error case 
that explicitly speaks to this.  Such as, "you have sent me an XML 
instance that is 900k long so far, perhaps you ought to get a hold of 
yourself".

4) The block contains lots of short, but very straightforward search 
sets.  Your server could just respond with IRIS <permissionDenied> or 
<limitExceeded> errors for every search set, or could use the new error 
code from #3.

-andy



_______________________________________________
Crisp mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/crisp