Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

[R1] Portable SDK for UPnP Devices (libupnp) glibc Implementation getaddrinfo() Function Remote Stack Overflow

Critical

Synopsis

On February 16, 2016 Google disclosed a stack overflow in glibc triggered via interaction between the getaddrinfo() function and specifically formed DNS responses designated CVE-2015-7547. This issue also appeared in glibc’s bug tracker back in July 2015. Google released a proof of concept via Fermin Serna’s github account.

The getaddrinfo() function helps programs resolve hostnames into IP addresses and therefore can be found in an incredible amount of software. Surprisingly, there have been very few (if any?) advisories discussing specific attacks on applications that use this common glibc function. By and large, companies are simply pushing out patches for glibc as that is typically quicker than doing analysis to determine if an application is vulnerable. Some individuals on Reddit tracked the advisories for a brief while but only scratched the surface of products and vendors impacted.

About libupnp

Portable SDK for UPnP Devices (aka libpunp) is one of the oldest universal plug-and-play stacks around and can use glibc. Punching “Portable SDK for UPnP Devices” into Shodan yields approximately 4.8 million hosts. These are almost exclusively embedded systems (routers, TVs, IoT oh my, etc.) Which means a few things:

  1. Very few will ever be patched.
  2. They will stay connected to the Internet until they die or are replaced with a new device that has the same libpunp implementation.
  3. ASLR and NX generally won’t be an issue for exploitation.

To our surprise, the first page of Shodan lists hosts running libupnp 1.3.1. That was released in May 2006 and superseded by 1.4.0 a month later!

libupnp has been villainized enough over the years so we'll try not to beat on that poor dead horse. It also gets a bad rap for implementing the IGD protocol, but this advisory is not specifically tied to that interface.

Using getaddrinfo()

libupnp 1.6.20 (the most recent release at the time of this discovery) uses getaddrinfo() in exactly one place: uri.c:parse_hostport(). Using a sample program distributed with libupnp, called tv_device, we can trigger this code via an HTTP SUBSCRIBE request to a valid event URL. How do we obtain a valid event URL? We will have to parse the tvdevicedesc.xml file advertised by the tv_device libupnp banner. We can send a SUBSCRIBE request to either /upnp/event/tvcontrol1 or /upnp/event/tvpicture1. Most importantly, we need to put a callback field in the SUBSCRIBE request. The callback field is what is going to be parsed by the parse_hostport() function. In order to trigger the getaddrinfo() code path we need to provide a hostname in the callback field. Tenable created a simple python script that would trigger getaddrinfo() if used against libupnp’s tv_device to share with the vendor.

Vulnerable Versions

The SUBSCRIBE code path is vulnerable all the way back to 1.6.7 (released 2010-10-04) and does not appear in version 1.6.6.

Solution

Since the vulnerable function is located in glibc, and libupnp does not ship glibc, administrators will need to to update glibc to 2.23 or later.

Disclosure Timeline

2016-09-21 - Issue discovered
2016-09-27 - Advisory drafted
2016-09-27 - Submitted for consideration to ZDI as bainesjr0013
2016-10-25 - Pinged ZDI for status
2016-10-31 - ZDI acknowledges ping. Will "nudge" this case.
2016-11-14 - ZDI "not interested in a new vector for this CVE"
2016-11-24 - Vendor notified via pupnp-devel@lists.sourceforge.net
2016-12-11 - Ticket #134 created on SF project page
2016-12-12 - Vendor asks for proposed solution/patch
2016-12-14 - Tenable provides input on how to handle
2017-01-20 - Ticket #134 closed

All information within TRA advisories is provided “as is”, without warranty of any kind, including the implied warranties of merchantability and fitness for a particular purpose, and with no guarantee of completeness, accuracy, or timeliness. Individuals and organizations are responsible for assessing the impact of any actual or potential security vulnerability.

Tenable takes product security very seriously. If you believe you have found a vulnerability in one of our products, we ask that you please work with us to quickly resolve it in order to protect customers. Tenable believes in responding quickly to such reports, maintaining communication with researchers, and providing a solution in short order.

For more details on submitting vulnerability information, please see our Vulnerability Reporting Guidelines page.

If you have questions or corrections about this advisory, please email advisories@tenable.com