Vulnerability in tinysvcmdns

Bug #1729668 reported by Talos Security Advisory
258
This bug affects 1 person
Affects Status Importance Assigned to Milestone
shairport-sync (Debian)
Fix Released
Unknown
shairport-sync (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

### Summary

An exploitable heap overflow vulnerability exists in the tinysvcmdns library version 2016-07-18. A specially crafted packet can make the library overwrite an arbitrary amount of data on the heap with attacker controlled values. An attacker needs send a dns packet to trigger this vulnerability.

### Tested Versions

tinysvcmdns 2016-07-18

### Product URLs

[https://bitbucket.org/geekman/tinysvcmdns](https://bitbucket.org/geekman/tinysvcmdns)

### CVSSv3 Score

10.0 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

### CWE

CWE-122 – Heap-based Buffer Overflow

### Details

The tinysvcmdns library is a MDNS responder implementation optimized for size, and is essentially a mini and embedded version of Avahi or Bonjour. It was found to be inside of the mdnsd daemon on the Circle with Disney device, and is used to enumerate devices within the same network as the Circle, such that it can later monitor or filter their traffic if the administrator/parent desires. While the majority of this bug is written in the context of the Circle with Disney device, this bug does apply to the tinysvcmdns library itself.

The mdnsd binary is bound to the normal IPv4 addressf of the Circle device, and also the hardcoded IPv6 link local address `FE80::C001:37FF:FE6C:0`. Since there is already another binary called mdns-scan, that is bound UDP port 224.0.0.251:5353, and also a modified dnsmasq server on UDP 0.0.0.0:53, it is believed that the only purpose of the mdnsd binary is to provide IPv6 auto-discovery.

Regardless, the mdnsd binary also responds and processes normal unicast DNS requests to UDP:5353, which is where this vulnerability lies. It does not appear that the disassembly is different from the tinysvcmdns source code in this vulnerable section.

The `nlabel_to_str` function in mdns.c is used to turn a series of name labels into a dotted representation of the domain name. For instance, when trying to `wget abcd.efgh.cachemonet.com`, the dns request will be separated into parts, as there is more than one suffix. The previous domain would look like this:

 0000 04 61 62 63 64 04 65 66 67 68 0a 63 61 63 68 65 .abcd.efgh.cache
 0010 6d 6f 6e 65 74 03 63 6f 6d 00 monet.com.

Where by each portion of the domain is separated by a 1-byte field describing the length of the next segment (\x04 => abcd, etc).

Normally, multi-label DNS names have some restrictions, as set forth by the RFC.

 3.1. Name space definitions

 Domain names in messages are expressed in terms of a sequence of labels.
 Each label is represented as a one octet length field followed by that
 number of octets. Since every domain name ends with the null label of
 the root, a domain name is terminated by a length byte of zero. The
 high order two bits of every length octet must be zero, and the
 remaining six bits of the length field limit the label to 63 octets or
 less.

 To simplify implementations, the total length of a domain name (i.e.,
 label octets and label length octets) is restricted to 255 octets or
 less.

However, the `nlabel_to_str` function does not do any sort of filtering on this input:

 // returns a human-readable name label in dotted form
 char *nlabel_to_str(const uint8_t *name) {
     char *label, *labelp;
 const uint8_t *p;

     assert(name != NULL);
     label = labelp = malloc(256); //[1]

     for (p = name; *p; p++) { //[2]
         strncpy(labelp, (char *) p + 1, *p);
         labelp += *p;
         *labelp = '.';
         labelp++;

         p += *p;
     }
     *labelp = '\0';
     return label;

We can see there is a fixed heap allocation of size 256 at [1], however, there's no limitation to how many bytes can be copied. As long as the end of a given label is not “\x00” [2], the strncpy's just keep flowing, allowing for an arbitrary write on the heap by anyone with network connectivity to the device.

### Credit

Discovered Lilith (>^.^)> Wyatt and Claudio Bozzato of Cisco Talos.
http://talosintelligence.com/vulnerability-reports/

Tags: patch

CVE References

Revision history for this message
Talos Security Advisory (regiwils) wrote :
Revision history for this message
Talos Security Advisory (regiwils) wrote :
Revision history for this message
Talos Security Advisory (regiwils) wrote :

Hello,

The Cisco Talos team found a security vulnerability impacting tinysvcmdns customers.

For further information about the Cisco Vendor Vulnerability Reporting and Disclosure Policy please refer to this document which also links to our public PGP key. http://www.cisco.com/web/about/security/psirt/vendor_vulnerability_policy.html

Please CC <email address hidden> on all correspondence related to this issue.

Revision history for this message
Leonidas S. Barbosa (leosilvab) wrote :

Hi,

Thanks for notify us about this issue.
Did you notify upstream yet? And did you apply for a CVE yet?

Revision history for this message
Talos Security Advisory (regiwils) wrote :

CVE-2017-12087 assigned

Revision history for this message
Talos Security Advisory (regiwils) wrote :
Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

Hi! Have you gotten a response from the upstream tinysvcmdns project yet?

Since the shairport-sync package is in the universe repository, it is community maintained. This means that the security team will not be fixing the package unless a community member contributes a debdiff for sponsoring that fixes the issue.

Obviously, that can't happen if upstream hasn't written a patch, or this bug remains private.

Revision history for this message
Talos Security Advisory (regiwils) wrote : Re: [Bug 1729668] Vulnerability in tinysvcmdns
Download full text (5.3 KiB)

Hello Marc,

Yes, they pushed a fix for this issue to the Bitbucket repository.

Kind Regards,

Regina Wilson
Engineer. Research
<email address hidden><mailto:<email address hidden>>

[cid:<email address hidden>]

On Nov 9, 2017, at 7:36 AM, Marc Deslauriers <<email address hidden><mailto:<email address hidden>>> wrote:

Hi! Have you gotten a response from the upstream tinysvcmdns project
yet?

Since the shairport-sync package is in the universe repository, it is
community maintained. This means that the security team will not be
fixing the package unless a community member contributes a debdiff for
sponsoring that fixes the issue.

Obviously, that can't happen if upstream hasn't written a patch, or this
bug remains private.

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1729668

Title:
 Vulnerability in tinysvcmdns

Status in shairport-sync package in Ubuntu:
 New

Bug description:

 ### Summary

 An exploitable heap overflow vulnerability exists in the tinysvcmdns
 library version 2016-07-18. A specially crafted packet can make the
 library overwrite an arbitrary amount of data on the heap with
 attacker controlled values. An attacker needs send a dns packet to
 trigger this vulnerability.

 ### Tested Versions

 tinysvcmdns 2016-07-18

 ### Product URLs

 [https://bitbucket.org/geekman/tinysvcmdns](https://bitbucket.org/geekman/tinysvcmdns)

 ### CVSSv3 Score

 10.0 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

 ### CWE

 CWE-122 – Heap-based Buffer Overflow

 ### Details

 The tinysvcmdns library is a MDNS responder implementation optimized
 for size, and is essentially a mini and embedded version of Avahi or
 Bonjour. It was found to be inside of the mdnsd daemon on the Circle
 with Disney device, and is used to enumerate devices within the same
 network as the Circle, such that it can later monitor or filter their
 traffic if the administrator/parent desires. While the majority of
 this bug is written in the context of the Circle with Disney device,
 this bug does apply to the tinysvcmdns library itself.

 The mdnsd binary is bound to the normal IPv4 addressf of the Circle
 device, and also the hardcoded IPv6 link local address
 `FE80::C001:37FF:FE6C:0`. Since there is already another binary called
 mdns-scan, that is bound UDP port 224.0.0.251:5353, and also a
 modified dnsmasq server on UDP 0.0.0.0:53, it is believed that the
 only purpose of the mdnsd binary is to provide IPv6 auto-discovery.

 Regardless, the mdnsd binary also responds and processes normal
 unicast DNS requests to UDP:5353, which is where this vulnerability
 lies. It does not appear that the disassembly is different from the
 tinysvcmdns source code in this vulnerable section.

 The `nlabel_to_str` function in mdns.c is used to turn a series of name labels into a dotted representation of the domain name. For instance, when trying to `wget abcd.efgh.cachemonet.com`, the dns request will be separated into parts, as there is more than one suffix. The previous d...

Read more...

Revision history for this message
Steve Beattie (sbeattie) wrote :
information type: Private Security → Public Security
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "tinysvcmdns-heapoverflow.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Revision history for this message
Chris Boot (bootc) wrote :

I maintain shairport-sync in Debian. The shairport-sync package in Debian is built with Avahi for mDNS and doesn't use the bundled tinysvcmdns. As far as I can tell, the Ubuntu version is a straight rebuild and thus should also be unaffected. Yes, the vulnerable code is in the source but the built binaries should not include it.

Revision history for this message
Chris Boot (bootc) wrote :
Changed in shairport-sync (Debian):
status: Unknown → Confirmed
Changed in shairport-sync (Debian):
status: Confirmed → Fix Released
Revision history for this message
Seth Arnold (seth-arnold) wrote :

Thanks for investigating and reporting upstream, Chris. It does indeed look like our packages should just be plain rebuilds, so I'll mark this 'Won't Fix'. (None of the descriptions feel quite right, but I do think it's fair to say that probably no one's going to bundle fixes for something that we don't build.)

Thanks

Changed in shairport-sync (Ubuntu):
status: New → Won't Fix
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.