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 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/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shairport-sync/+bug/1729668/+subscriptions