Hi,
On 2009/09/15, at 23:35, Peter Saint-Andre wrote:
On 7/31/09 8:59 PM, Peter Saint-Andre wrote:
On 7/22/09 6:28 AM, Waqas Hussain wrote:
=== Attack 1 ===
<identity category='client' type='pc' name='SomeClient'/>
<feature var='http://jabber.org/protocol/muc'/
<http://jabber.org/protocol/muc'/>>
and
<identity category='client'
type='pc' name='SomeClient<http://jabber.org/protocol/muc'/
<http://jabber.org/protocol/muc'/>>
both result in the same verification
string: sha1('client/pc//SomeClient<http://jabber.org/protocol/
muc<').
I'm told the original intention was to use escaped strings,
Correct: the "<" delimiter was chosen for exactly that reason! Thus
the
disco identity name "SomeClient<http://jabber.org/protocol/muc"; is
to be treated as a literal string without converting the four
consecutive characters "&" and "l" and "t" and ";" into "<".
Otherwise
we could truly have a trivially easy attack.
I have added the following warning to my working copy:
Note: If the four characters '&', 'l', 't', ';' appear
consecutively in any of the factors of the verification string
S (e.g., a service discovery identity of
'SomeClient<http://jabber.org/protocol/muc') then that
string of characters MUST be treated as literally '<' and
MUST NOT be converted to the character '<', because completing
such a conversion would open the protocol to trivial attacks.
http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0115.xml?r2=3373&r1=2855
If I read this correctly, implementations are supposed to use the
escaped or raw version of the text. Does this apply only to < or to
all other invalid chars in XML? That doesn't seem right because you
could have problems with &lt;.
See below for my proposal.
=== Attack 2 ===
This attack makes use of service discovery extensions.
As I understand it, Joe is proposing that the first-sorted service
discovery extension needs to be something like this:
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>!</value>
</field>
</x>
[...]
2. Structural information is lost (leading to attacks 2 and 3)
For the major attack here, I think that a special hidden FORM_TYPE
might
suffice.
This seems a bit on the "hackish" side.
Dave Cridland suggested using NUL as the delimiter, which is
illegal in
XML and UTF-8.
This is the basis of my proposal.
The way I see it we need to encode three types of information:
* identities;
* features;
* extensions;
each one with several instance, in a way that:
* inside a type, each encoded instance does not affect the others;
* each encoded type of information does not affect the other.
If we take the text of each attribute and node after XML decoding (so
'&' => '&', '<' => '>'), we apply the same protocol as
specified in v1.5 of XEP-0115 with the following changes:
* use \0 (NUL) as the separator instead of '>' and '/': NUL is an
invalid character in XML so it MUST NOT be present in the collected
texts;
* add an extra \0 (NUL) after each type of information block, even
if not present. So an empty disco#info response still encodes to
\0\0\0, one for each of identities, features, and extensions. The
extra \0 provides a barrier between types.
Using example 5.2 of v1.5, the string would be:
1. S = ''
2. Only one identity: "client/pc"
3. S = 'client\0pc\0\0Exodus 0.9.1\0\0'
4. Sort the features: "http://jabber.org/protocol/caps";, "http://jabber.org/protocol/disco#info
", "http://jabber.org/protocol/disco#items";, "http://jabber.org/protocol/muc
".
5. S = 'client\0pc\0\0Exodus 0.9.1\0\0http://jabber.org/protocol/caps\0http://jabber.org/protocol/disco#info
\0
http://jabber.org/protocol/disco#items\0http://jabber.org/protocol/muc
\0\0'
6. No extensions, add last marker;
7. S = 'client\0pc\0\0Exodus 0.9.1\0\0http://jabber.org/protocol/caps\0http://jabber.org/protocol/disco#info
\0
http://jabber.org/protocol/disco#items\0http://jabber.org/protocol/muc
\0\0\0'
=== A new XEP and namespace? ===
Dave suggested "We can just use a new hash algorithm name, that
should
surely have a similar end-result, but be treated as an unknown
hash by
existing XEP-0115 implementations."
Personally I would prefer a clean new XEP. We already have a Legacy
Format (possibly in wider use than the current format). Updating
XEP-0115 may lead to having Legacy and Legacy-Legacy formats. But
I'm
not particularly opposed to it either.
Naturally the XSF is open to proposals, so if someone wants to write a
new XEP about this, feel free.
We have two versions of 115, the initial one that was subject to caps
poisoning because there was no validation about the information
present in the presence announcement and the response of disco#info,
and this second version, with the signature of the disco#info response.
I don't see this as a third version, but as a fixed version 2. The
first release of version 2 was broken, and we are fixing it. The only
thing that would change is the algorithm to generate the version.
Given that we already discussed the problems when we changed from
version 1 to version 2, I don't think we can add much to that
discussion if we consider this another version.
Given that very few clients implemented 1.5 and given that 1.5 is a
security risk, I think its better to have a 1.6 without those risks.
Best regards,
