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