Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 459366 (CVE-2013-1769) - <net-voip/telepathy-gabble-0.16.6: NULL pointer dereference when trying to hash caps containing pathological data forms (CVE-2013-1769)
Summary: <net-voip/telepathy-gabble-0.16.6: NULL pointer dereference when trying to ha...
Status: RESOLVED FIXED
Alias: CVE-2013-1769
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
URL: https://bugzilla.redhat.com/show_bug....
Whiteboard: B3 [noglsa]
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-26 21:38 UTC by Agostino Sarubbo
Modified: 2014-06-09 01:33 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2013-02-26 21:38:04 UTC
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
Comment 1 Gilles Dartiguelongue (RETIRED) gentoo-dev 2013-02-27 13:30:25 UTC
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.
Comment 2 GLSAMaker/CVETool Bot gentoo-dev 2014-01-27 09:59:27 UTC
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.
Comment 3 Pacho Ramos gentoo-dev 2014-05-29 20:00:43 UTC
should be solved in 0.18.x
Comment 4 Pacho Ramos gentoo-dev 2014-06-01 13:28:21 UTC
fixed in telepathy-gabble-0.18.2, stabilized in bug #508862
Comment 5 Sean Amoss (RETIRED) gentoo-dev Security 2014-06-01 15:42:01 UTC
I have not found any references that this also affects net-voip/telepathy-salut. 

GLSA vote: no.
Comment 6 Yury German Gentoo Infrastructure gentoo-dev 2014-06-09 01:33:15 UTC
GLSA Vote: no

No GLSA - Closing Bug as Resolved