On Wed, Aug 31, 2011 at 7:10 AM, Peter Saint-Andre <[email protected]> wrote: > On 8/30/11 5:41 PM, Waqas Hussain wrote: >>> 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 '/' >
Most protocol attacks are based on unexpected input. Attackers wouldn't really care whether the values they send are registered or usable in any way, as long as the attack succeeds. I don't think you are proposing all caps handling entities ship with a copy of the registry and fail on anything not included. >>>> 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> > I know Miranda and Tkabber send software version. Probably many others. Can we gather stats on jabber.org for this? > > Peter > -- Waqas Hussain
