On "max. tag nesting depth" in the Kolab-Format spec

[Gunnar Wrobel]

Quoting "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:

> Florian v. Samson wrote:
>> Hi Georg,
>>
>> Am Freitag, 15. Juli 2011 um 10:37:33 schrieb Georg C. F. Greve:
>> > Just very briefly, I will come back to kolab-format@ with a bit more time
>> > in the next weeks, but I think some more work needs to be done on showing
>> > the rationale for a hard-coded nesting depth limit:
>> >
>> > On Friday 15 July 2011 10.12:49 Florian v. Samson wrote:
>> > > In short: Why not?
>> >
>> > 	"640K ought to be enough for anybody."
>> >
>> > There is an inherent problem with foreseeing absolute numbers and limits
>> > in computing, and changing this later if/when we hit that barrier will be
>> > very expensive for all clients.
>>
>> While I do understand this aspect and have no issue with raising the limit
>> to e.g. 127, I do agree with Bernhard that there ought to be one.
>>
>
> I disagree.
>
> Prevention of the parsing of nested XML potentially resulting in denial of
> service is hardly Kolab Format's purvue, but could instead be  
> implemented, for
> example, in a parsing library -by means of limited read-ahead- and/or in or
> through the client.
>
> Also, *specifying* the maximum level of nesting does not *prevent*  
> the maximum
> level of nesting from being exceeded. As such, clients would have to 1) read,
> 2) count, 3) hit the limit, 4) ignore further nesting levels, but this is an
> absolutely flawed implementation of trying to implement DoS prevention, and
> very costly to change once the limit has to be raised. Insert here a  
> remark on
> road speed limits, and IPv4 -> IPv6.
>
> Furthermore, if the limit in nesting levels is to be implemented to prevent a
> potential client denial of service, I would argue you also require a  
> limit for
> string lengths, number of sequential tags, content characters and maximum
> number of folders for a Kolab account.

And I think the latter one would even be an easier DOS attack than  
forging an XML object. I could imagine that Horde would kill itself if  
somebody would create and share 10.000 IMAP folders. But maybe we  
should refrain from discussing the various means of killing Kolab  
servers on a public mailing list :)

I think Georg is right in saying that there are too many vectors to  
attack once we provide a user with access to the IMAP system and  
Jeroen underlined that. Yes, there should be guards against such  
attacks but the clients are responsible for securing against that and  
it is something that just does not belong into the Kolab format spec.

Cheers,

Gunnar

>
> Limiting the level of nesting is, like Georg says, not sustainable.
>
> Kind regards,
>
> Jeroen van Meeuwen
>
> --
> Senior Engineer, Kolab Systems AG
>
> e: vanmeeuwen at kolabsys.com
> t: +44 144 340 9500
> m: +44 74 2516 3817
> w: http://www.kolabsys.com
>
> pgp: 9342 BF08
>
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format

-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de