Daniel Gultsch, 2015/12/20
CVE-2015-8688: Gajim doesn’t verify the origin of roster pushes thus allowing third parties to modify the roster.
Alice is using the latest version of Gajim (0.16.4) and logged in as alice@siacs.eu/Gajim. She has her boyfriend Bob (bob@siacs.eu) saved under Bob in her roster. Gajim shows Bob’s JID only in the tooltip of the respective roster entry.
Eve, jealous of Bob, wants to intercept Alice’s messages to Bob. She crafts two special stanzas (XMPP packets) and sends those to Alice.
<iq type="set" to="alice@siacs.eu/Gajim">
<query xmlns='jabber:iq:roster'>
<item subscription="remove" jid="bob@siacs.eu"/>
<item subscription="both" jid="eve@siacs.eu" name="Bob" />
</query>
</iq>
<presence to="alice@siacs.eu/Gajim">
<show>online</show>
</presence>
The first stanza removes Bob from Alice’s roster while at the same time adding Eve under the name of Bob to it. The second stanza marks herself as being online. Alice roster will look exactly the same exact for the tooltip.
The next time Alice opens a conversation with, what she thinks is her boyfriend Bob, she will really be opening a conversation with Eve.
Doing the same to Bob - who is also using Gajim - Eve can listen in to the entire conversation between the two.
If Alice’s server offers Roster Versioning those changes will even be persistent across restarts. Otherwise Eve would have to repeat sending those stanzas each time Alice goes online.
Gajim should verify the origin of a roster push stanza. Those stanzas should only parsered if they are coming from the servers JID or the users own JID.
If Eve is not subscribed to Alice’s presence updates she has to guess her resource to make this attack happen. However Gajims default resource of Gajim makes this very easy. If Gajim would be using random strings (for example UUIDs) as resource this attack could have been prevented. (But of course still possible if Eve had presence subscription.)