A total of 6.1 million devices – smart phones, routers, smart TVs – are currently at risk to remote code execution attacks due to vulnerabilities that have been fixed since 2012.
The vulnerabilities exist in the Portable SDK for UPnP™ Devices, also called libupnp. This particular library is used to implement media playback (DLNA) or NAT traversal (UPnP IGD). Apps on a smartphone can use these features to play media files or connect to other devices within a user’s home network.
These vulnerabilities were actually fixed in December 2012, however many apps still use the older, vulnerable version of the SDK. We found 547 apps that used older versions of libupnp, 326 of which are available on the Google Play store, including high-profile apps such as Netflix and Tencent QQMusic. These are very popular apps that put millions of users in danger; aside from mobile devices, routers, and smart TVs are all at risk as well.
Figure 1. Vulnerable smart TV
How the vulnerability works
The vulnerability lies in how the libupnp library handles Simple Service Discovery Protocol (SSDP) packets. This protocol is part of the Universal Plug N’ Play (UPnP) standard. The stack overflow occurs during this process, and requires that the UDP port 1900 be open:
Figure 2. Port scan of affected system showing open port
A specially crafted packet can be used to overflow buffers. In the code below, the TempBuf buffer can overflow and cause a crash.
Figure 3. Code showing buffer which can be overflowed
With further research an exploit could be used not just to cause a crash, but to run arbitrary code on an affected device. The ability to run arbitrary code would give the attacker the ability to take control of the device, as on a PC. We have seen exploits in the wild targeting devices that do not use mitigation protections such stack canaries, DEP, and ASLR. For well protected systems, we do not know of exploits that are currently capable of remote code execution.
We have confirmed that in at least 20 apps, the vulnerable libupnp library can be activated. These are:
|Common Name||Package Name|
|HexLink Remote (TV client)||hihex.sbrc.services|
|HexLink-SmartTV remote control||com.hihex.hexlink|
|Hisense Android TV Remote||com.hisense.commonremote|
|nScreen Mirroring for Samsung||com.ht.nscreen.mirroring|
|Ooredoo TV Oman||com.ooredootv.ooredoo|
|PictPrint – WiFi Print App –||jp.co.tandem.pictprint|
|Smart TV Remote||com.hisense.common|
|에브리온TV (무료 실시간 TV)||com.everyontv|
Table 1. Some affected apps
We will focus on two apps from the above list that are particularly high profile. One is the QQMusic app, which as 100 million users in China and has been downloaded 1-5 million times from the Google Play store. When it is launched, it activates libupnp for DLNA playback. However, it uses version 1.6.17 of the SDK, a version that dates back to April 2012.
Figure 4. Embedded vulnerable SDK
Figure 5. Stack with controlled data
The Netflix app is a very popular app on Android, and it also used what we thought was an old version of libupnp – 1.6.13. The SDK is used when the Android app is used to control Netflix on another device, such as a PlayStation 3.
Figure 6. Embedded SDK in Netflix
However, upon further clarification with Netflix, we learned that Netflix uses their own fork of libupnp due to an API that is no longer a part of newer libupnp versions. However, their fork contains the fixes from newer versions of libupnp as well, so we believe they are not affected by potential remote code execution attacks targeting this vulnerability.
SDKs can also rely on other SDKs in order to run. The Linphone SDK provides voice over IP (VoIP) services to various applications. The libupnp SDK is one of several options used by the Linphone SDK to provide NAT traversal via UPnP; if this option is chosen the vulnerable service will be activated.
Figure 7. Linphone crashing due to use of libupnp
We informed Linphone and Tencent (developers of the QQMusic app) of the problems in their apps. Both have committed to releasing fixes. We continue to investigate other vulnerable devices or apps, and urge all potentially affected vendors to release fixes.
- November 14 – Issue disclosed to Linphone and Tencent.
- November 16 – Tencent acknowledged the vulnerability.
- November 18 – Linphone acknowledged the vulnerability.
- November 23 – Tencent released an update for their Android app. (version 188.8.131.52).
- November 25 – Linphone released a fix for this issue.