-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/31/09 8:59 PM, Peter Saint-Andre wrote: > On 7/22/09 6:28 AM, Waqas Hussain wrote: >> Peter asked me to post a summary of the pre-image attacks I found and >> the discussion which followed, so here it is. > > Thank you for the report. > >> === Introduction === > >> On reading XEP-0115: Entity Capabilities, I discovered that it >> is trivially easy to do a preimage attack. That is, given a >> service discovery response, it is trivially easy to create a different >> service discovery response which has the same verification string. This >> can obviously be used to poison caps caches, effectively eliminating any >> security advantage of using hashes. > >> === 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 >> === 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> Because this sorts first, it would provide a separator between features and extensions. We just need to find a string that would be unique here and sort first (e.g., perhaps even the NUL character). > This raises the question of why we really need to encapsulate service > discovery extensions in entity capabilities. We had consensus that we wanted to do this in order to avoid floods of iq:version requests. >> Basically, identities, features, and service discovery extensions can be >> replaced by a different set of service discovery extensions. A very >> basic example using the same disco example used in Attack 1: > >> <identity category='client' type='pc' name='SomeClient'/> >> <x xmlns='jabber:x:data' type='result'> >> <field var='FORM_TYPE' type='hidden'> >> <value>http://jabber.org/protocol/muc</value> >> </field> >> </x> > >> === Attack 3 === > >> <feature var='http://jabber.org/protocol/muc'/> > >> can be replaced by > >> <identity category='http:' type='' xml:lang='jabber.org' >> name='protocol/muc'/> I agree with Joe Hildebrand that we should forbid empty 'type' attributes. This can be done in XEP-0030. >> === Attack 4 === > >> <identity category='http:' type='' xml:lang='jabber.org' >> name='protocol/muc'/> > >> can be replaced by > >> <identity category='http:' type='' xml:lang='jabber.org/protocol' >> name='muc'/> No empty 'type' attributes. >> === Analysis === > >> The basic problems in the caps algorithm are: > >> 1. Delimiters are not escaped in the concatenated strings (leading to >> attacks 1 and 4) By "delimiters" do you mean the "/" character? >> 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. >> === The threat === > >> Poisoning caps cashes isn't trivially easy. It requires knowing when the >> cache is initialized, and attempting the attack before legitimate >> presentities populate the cache. But this isn't terribly difficult >> either. Many servers do have scheduled reboots, and it isn't necessarily >> infrequent. A poisoned cache may stay poisoned for extended periods of >> time, and would lead to unexpected behavior. > >> === Attempting to fix the algorithm === > >> Peter suggested forbidding '<' in the strings being concatenated. This >> can be done for features and identities, but does it make sense for >> strings in service discovery extensions (which may very well include >> user input, e.g., http://xmpp.org/extensions/xep-0045.html#example-8)? That's a good point. >> Joe Hildebrand (one of the authors of the XEP) mentioned that his >> intention was that you would escape any "<" to "<" in feature names. >> But this isn't specified in the XEP and isn't obvious. Making this >> change now would break existing implementations (I'm sure <>&'" are >> being used out there in service discovery extensions). IMHO that was a minor spec bug. The '<' character was chosen for exactly that reason. >> Attack 4 might be mitigated by forbidding '/' in the 'category', 'type' >> and 'xml:lang' attributes of <identity> elements (I dislike that by the >> way). As far as I can see, there is no way of fixing attacks 2 and 3 >> other than fundamentally changing the algorithm. I'm not convinced yet, but I'm open to argument. >> === Attempting to create a new algorithm === > >> Peter suggested that the new algorithm may be based on just feature names. > >> Dave Cridland suggested using NUL as the delimiter, which is illegal in >> XML and UTF-8. > >> This needs some thought though. Does it never make sense for a >> presentity to notify its subscribers about changes to its identities or >> service discovery extensions? There was consensus about killing off >> XEP-0128 (Service Discovery Extensions), with comments like 'cast out', >> 'inherently evil', 'more evilness lurking there' and 'It's just wrong'. >> I quoted those because I happen to agree. This probably deserves a >> separate thread. > >> === 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. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqwFrEACgkQNL8k5A2w/vz7FQCgv2/In6HadzJqkQpp2NaMq9tk 1pQAn3BHNR1Cryx9cQLrQCK3gJt+jqLc =9YDp -----END PGP SIGNATURE-----
