An issue was discovered in GUPnP before 1.0.7 and 1.1.x and 1.2.x before 1.2.5. It allows DNS rebinding. A remote web server can exploit this vulnerability to trick a victim's browser into triggering actions against local UPnP services implemented using this library. Depending on the affected service, this could be used for data exfiltration, data tempering, etc.
Created gupnp tracking bugs for this issue: Affects: fedora-all [bug 1964093]
Flaw summary: The GuPNP service (device server) uses HTTP requests to communicate with UPnP "Control Points" (clients). The flaw is that the service does not perform validation on the HTTP HOST header. This means that a malicious web server could serve a malicious script which performs a DNS rebinding attack[1]. DNS rebinding attacks map a given host name to a private IP on the local network in a malicious way. In doing this, the malicious script and server can coerce a web browser into making a request to a GuPnP service on the local network, extract potentially sensitive data, send commands to the GuPnP service, and etc... An attack could look like this: 1. The victim user browses to somemaliciouswebsite.com 2. somemaliciouswebsite.com serves up a malicious javascript script that is executed by the browser. The script performs a DNS rebinding attack that changes the DNS entry for somemaliciouswebsite.com to map to a local IP of a UPnP service using GuPnP. 3. Subsequent requests are made to somemaliciouswebsite.com, but instead of being sent to the original website, the requests are now sent to the device using GuPnP on the local network. This bypasses same-origin policy because the host name is the same, but the DNS record has been changed to a different (now private/local) IP. 4. The script can send commands via HTTP to the local GuPnP device, gathering service information, browsing and retrieving file content on the device (such as using ContentDirectory service[2]), and eventually disclosing it to the attacker, or performing other malicious commands. However, in step #4, the HTTP HOST header would be set to somemaliciouswebsite.com, instead of the IP/port of the device using GuPnP. Therefore, by validating the HTTP HOST header content to ensure that it is addressed to the proper host (the local GuPnP service's address), this attack can be mitigated on the GuPnP server side. The upstream patch does this. 1. https://en.wikipedia.org/wiki/DNS_rebinding#How_DNS_rebinding_works 2. http://www.upnp.org/specs/av/UPnP-av-ContentDirectory-v3-Service.pdf
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:2363 https://access.redhat.com/errata/RHSA-2021:2363
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2021-33516
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.2 Extended Update Support Via RHSA-2021:2422 https://access.redhat.com/errata/RHSA-2021:2422
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2021:2417 https://access.redhat.com/errata/RHSA-2021:2417
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.1 Extended Update Support Via RHSA-2021:2459 https://access.redhat.com/errata/RHSA-2021:2459