From ${URL} : Will Thompson (will.thompson@collabora.co.uk) reports: Calculating a XEP-0115 hash involves sorting the fields of data forms in the contact's capabilities according to their field name. wocky_caps_hash_compute_from_lists() does this using this function: gint wocky_data_form_field_cmp (const WockyDataFormField *left, const WockyDataFormField *right) { return strcmp (left->var, right->var); } This will obviously crash if either ->var is NULL, but WockyDataForm validates forms it parses so this shouldn't happen, right? Unfortunately, http://xmpp.org/extensions/xep-0004.html#protocol-field says: > If the <field/> element type is anything other than "fixed" (see below), it > MUST possess a 'var' attribute that uniquely identifies the field in the > context of the form (if it is "fixed", it MAY possess a 'var' attribute). And WockyDataForm implements this correctly: var = wocky_node_get_attribute (node, "var"); if (var == NULL && type != WOCKY_DATA_FORM_FIELD_TYPE_FIXED) { DEBUG ("field node doesn't have a 'var' attribute; ignoring"); return FALSE; } So we have a remotely-triggered DoS: send Gabble a <presence> with a caps hash; include a form with an anonymous fixed field in the reply; boom. Since anyone can send presence to anyone else, and Gabble always looks up any caps it sees in any presences it receives. (Note that this is a presence leak, too; another bug, I think.) I have some fixes; patches to follow. I will also suggest that http://xmpp.org/extensions/xep-0115.html be updated to mention this. External references: https://bugs.freedesktop.org/show_bug.cgi?id=61433 http://lists.freedesktop.org/archives/telepathy-bugs/2013-February/021155.html http://xmpp.org/extensions/xep-0115.html
yay, I guess this also affects telepathy-salut (which has a copy of wocky as well). If so, I guess it is time to think about splitting this lib out of those two packages.
CVE-2013-1769 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-1769): A certain hashing algorithm in Telepathy Gabble 0.16.x before 0.16.5 and 0.17.x before 0.17.3 allows remote attackers to cause a denial of service (NULL pointer dereference and crash) via a crafted message.
should be solved in 0.18.x
fixed in telepathy-gabble-0.18.2, stabilized in bug #508862
I have not found any references that this also affects net-voip/telepathy-salut. GLSA vote: no.
GLSA Vote: no No GLSA - Closing Bug as Resolved