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

Florian v. Samson florian.samson at bsi.bund.de
Fri Jul 15 10:12:49 CEST 2011


Hi Gunnar, hi Bernhard,

separating this topic out, in order to finalise this aspect "max. tag 
nesting depth".

Am Freitag, 15. Juli 2011 um 05:47:50 schrieb Gunnar Wrobel:
> Quoting "Florian v. Samson" <florian.samson at bsi.bund.de>:
> > Am Montag, 20. Juni 2011 um 10:28:12 schrieb Georg C. F. Greve:
> >> On Monday 20 June 2011 10.01:19 Florian v. Samson wrote:
> >> > 
> >> > ...
> >> > 
> >> > 3. The depth of nesting XML-tags MUST be limited to 7 levels at
> >> > most. {A suggestion from Bernhard in order to limit the size of and
> >> > parsing efforts for Kolab-objects, which otherwise may be used for
> >> > Denial-of-Service attacks.  I picked the "7" as an educated guess
> >> > (i.e. some considerations done, but not at all exhaustive).}
> >>
> >> I would be interested in the threat scenario.
>
> Me as well here. And to stay in line with what I said above: Do you
> have an example of something that would immediately kill the parser? 

"Which one of the many Kolab-XML parsers?"
Well, it seems that many developers think of their (own) parser as a 
reference, but no one (including me) is willing to look at all of them, and 
not all parser developers are permanently monitoring this mailing-list: see 
<http://kolab.org/about-kolab-clients.html> (I see ca. 10 Kolab-XML parser 
implementations there)
Hence I just wanted to stay on the safe side.

Well, it was Bernhards suggestion; I just thought that limiting nesting 
depth basically makes sense.

But as you and Georg do not follow these considerations, I would be very 
interested in a scenario (or even just an idea) when a nesting depth of 
more than 7 levels may be applicable.

> ...
>
> So do we really need to specify something in the format specs?

In short: Why not?

You have not argued against any of the dangers I pointed out:

> > Denial of Service for all clients accessing and interpreting that
> > Kolab-object.
> >
> >> The storage format is accessed only by authorized clients,
> >
> > Uh, who "authorises" Kolab-clients?
> >
> >> so clients that have been authorized by the user to access the
> >> information.
> >
> > No, definitely not.
> > - Step 1: A malicious Kolab-user creates a few Kolab-XML bombs, each
> > with a nesting level > 10.000 (those Kolab-Objects will be a couple of
> > 10 KB in size, but one could use alternatively more smaller
> > Kolab-objects instead) and puts them into his shared IMAP-folder, to
> > which he grants all users on this Kolab-server access.
> > - Step 2: All users on this Kolab-server will be DOSsed on their next
> > sync, regardless of the individual client used.
> >
> > Hence, no "authorised Kolab-client" involved, and not even a malicious
> > one. The malicious Kolab-user can upload the forged Kolab-object and
> > set the access rights on this IMAP-folder "List & Read" for all
> > IMAP-users with any IMAP-tool or -client, including those which do not
> > understand Kolab-XML.
> >
> >> If the client is malicious - which seems to be assumed here -
> >
> > Not necessarily, see above.
> >
> >> I don't see  how an XML nesting bomb is the most likely scenario when
> >> the client might as well delete/falsify/make inconsistent the entire
> >> object/database.
> >
> > Ugh, that is way more complicated: why should an attacker take that
> > route, when there is an easier one.
> > And eliminating the easiest attack vector (and the most easy to
> > eliminate) is always a step which makes formerly harder attack vectors
> > becoming the easiest, thus interesting for attackers.
> >
> >> > b. Do we need similar, but separated statements for XML-attributes?
> >>
> >> Yes, imho. But I am not sure it would need to be separate, the two
> >> seem closely enough related.
> >
> > Can you (or someone) please come up with a suggestion (i.e. a paragraph
> > WRT XML-attributes), which fits somewhere in this context and the draft
> > text.


Cheers
 	Florian




More information about the format mailing list