On 8/30/11 5:41 PM, Waqas Hussain wrote: > On Wed, Aug 31, 2011 at 1:41 AM, Peter Saint-Andre <[email protected]> wrote: >> Replying to myself before I reply to the latest message from Waqas. :) >> >> On 8/30/11 12:37 PM, Peter Saint-Andre wrote: >> >>> So far, two of the attacks (#3 and #4) that you have described (via >>> examples only) depend on violations of the XML spec and XEP-0030. >>> >>> Another of the attacks (#1) depends on converting the literal string >>> "<" to "<", which we've said for years now is incorrect. >> > > Err, while we may have said '<' is bad in disco response text and > attribute values, you have phrased it wrong here. XML attribute node > and text node values are the unescaped '<', not the escaped '<' > which is just the serialization of the actual value. Past the XML > parser, all code sees '<'. What you are saying is it be re-escaped at > that level.
Yes, sorry. >> Can we agree that attacks #1, #3, and #4 are easily overcome by proper >> handling of inputs? >> > > Those examples, yes. The attack, no. Read my response to your other > email for a description of the general attack. Presented below are > variations of these attacks which the new 'proper handling of inputs' > doesn't catch. > > Let's assume we have entirely disallowed '<'. And we validate > <identity/> attributes to be valid. > > <identity category='a' type='b' name='c'/> > is the same as > <feature var='a/b//c'/> > > <feature var='http://jabber.org/a/b/c'/> > is the same as > <identity category='http://jabber.org' type='a' xml:lang='b' name='c'/> > > <identity category='http://jabber.org' type='a' xml:lang='b' name='c/d'/> > is the same as > <identity category='http://jabber.org' type='a/b' xml:lang='c' name='d'/> So, to use examples closer to real life... EXAMPLE 1 <identity category='client' type='pc' name='QuxChat'/> is the same as: <feature var='client/pc//QuxChat'/> EXAMPLE 2 <feature var='http://jabber.org/protocol/caps'/> is the same as: <identity category='http://jabber.org' type='protocol' xml:lang='caps'/> note: "http://jabber.org"; and "protocol" are not registered categories and types at http://xmpp.org/registrar/disco-categories.html note: "caps" is not a registered language tag, although if you visit http://www.iana.org/assignments/language-subtag-registry I'm sure you can find interesting entries that are legitimate. EXAMPLE 3 <identity category='http://jabber.org' type='a' xml:lang='b' name='c/d'/> is the same as <identity category='http://jabber.org' type='a/b' xml:lang='c' name='d'/> note: none of the types registered at http://xmpp.org/registrar/disco-categories.html contain '/' >>> Attack #2 can be mitigated by forbidding forms without fields in >>> XEP-0068 and XEP-0128. >> >> Regarding attack #2, one approach, which some folks on the formerly evil >> former Jabber team in Denver just discussed IRL, is to simply ban >> XEP-0128 forms from computation of the caps hash. The only legitimate >> use of XEP-0128 that anyone has ever tried to standardize was XEP-0232, >> but we were never able to reach consensus on that spec and it has been >> in the Deferred state for over two years. > > This is a fundamental change in the algorithm. By fundamental change I > mean entities using the older and newer versions will not be able to > interoperate. This is a new algorithm pretending to be the old one. > There are probably a lot of deployed clients which include disco > extensions in their disco results. As far as I can see, only Coccinella supports service discovery extensions, and then only for questionable purposes: <x xmlns='jabber:x:data' type='result'> <field var='FORM_TYPE' type='hidden'> <value>http://coccinella.sourceforge.net/protocol/servers</value> </field> <field var='putget_port'> <value>8234</value> </field> <field var='http_port'> <value>8077</value> </field> <field var='ip'><value>194.25.44.218</value></field> </x> > Now I have to ask, what is the motivation for going this far in > keeping the same XEP that you are willing to update the algorithm in a > non-backwards compatible way? It doesn't seem to be to not force > developers to write more code. All these fixes are going to lead to > more code. Next thing we know, we'll be validating xml:lang is > following the large BNF specified in RFC 4646. It doesn't seem to be > interop, or you wouldn't suggest this change. What is it then? I am simply exploring the problem space so that we have a good understanding of what needs to be fixed. Peter -- Peter Saint-Andre https://stpeter.im/
