Bug 915962 (CVE-2013-1769) - CVE-2013-1769 telepathy-gabble: NULL pointer dereference when trying to hash caps containing pathological data forms
Summary: CVE-2013-1769 telepathy-gabble: NULL pointer dereference when trying to hash ...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2013-1769
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 915963 915966 917769
Blocks: 916244
TreeView+ depends on / blocked
 
Reported: 2013-02-26 21:21 UTC by Kurt Seifried
Modified: 2021-02-17 08:00 UTC (History)
5 users (show)

Fixed In Version: telepathy-gabble 0.16.5, telepathy-gabble 0.17.3
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-25 20:48:12 UTC


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 61433 0 None None None Never

Description Kurt Seifried 2013-02-26 21:21:16 UTC
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

Comment 1 Kurt Seifried 2013-02-26 21:22:15 UTC
Created telepathy-gabble tracking bugs for this issue

Affects: fedora-all [bug 915963]

Comment 2 Kurt Seifried 2013-02-26 21:23:04 UTC
Created telepathy-gabble tracking bugs for this issue

Affects: epel-6 [bug 915966]

Comment 4 Fedora Update System 2013-03-19 19:59:33 UTC
telepathy-gabble-0.16.5-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.