Bug 26918 - gssdp/gupnp new security issue CVE-2020-12695
Summary: gssdp/gupnp new security issue CVE-2020-12695
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 7
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL:
Whiteboard: MGA7-64-OK
Keywords: advisory, validated_update
Depends on:
Blocks:
 
Reported: 2020-07-08 00:24 CEST by David Walser
Modified: 2021-06-28 14:49 CEST (History)
6 users (show)

See Also:
Source RPM: gssdp-1.2.1-1.mga7.src.rpm, gupnp-1.2.1-1.mga7.src.rpm
CVE: CVE-2020-12695
Status comment:


Attachments

Description David Walser 2020-07-08 00:24:19 CEST
Upstream has announced a security issue on June 23:
https://mail.gnome.org/archives/gupnp-list/2020-June/msg00000.html

The issue is fixed in 1.2.3.
Comment 1 Lewis Smith 2020-07-09 21:09:19 CEST
No evident maintainer for either of these packages, so having to assign this globally.

Assignee: bugsquad => pkg-bugs

Comment 2 Nicolas Salguero 2020-07-13 10:55:18 CEST
Suggested advisory:
========================

The updated packages fix a security vulnerability:

The Open Connectivity Foundation UPnP specification before 2020-04-17 does not forbid the acceptance of a subscription request with a delivery URL on a different network segment than the fully qualified event-subscription URL, aka the CallStranger issue. (CVE-2020-12695)

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12695
https://mail.gnome.org/archives/gupnp-list/2020-June/msg00000.html
========================

Updated packages in core/updates_testing:
========================
gssdp-1.2.3-1.mga7
lib(64)gssdp1.2_0-1.2.3-1.mga7
lib(64)gssdp-devel-1.2.3-1.mga7
lib(64)gssdp-gir1.2-1.2.3-1.mga7
lib(64)gupnp1.2_0-1.2.3-1.mga7
lib(64)gupnp-devel-1.2.3-1.mga7
lib(64)gupnp-gir1.2-1.2.3-1.mga7

from SRPMS:
gssdp-1.2.3-1.mga7.src.rpm
gupnp-1.2.3-1.mga7.src.rpm

Status: NEW => ASSIGNED
CC: (none) => nicolas.salguero
CVE: (none) => CVE-2020-12695
Assignee: pkg-bugs => qa-bugs

Comment 3 Herman Viaene 2020-07-26 14:18:53 CEST
MGA7-64 Plasma on Lenovo B50
No installation issues
At CLI:
$ gssdp-device-sniffer
opens a window which lists packages sniffed on the network. Selecting one of those gives below more details such as:
Received on: Sun Jul 26 14:12:44 2020

Headers:

LOCATION: http://192.168.2.15:49000/MediaServerDevDesc.xml
Server:<my router> UPnP/1.0 AVM FRITZ!Box 7490 113.07.01
CACHE-CONTROL: max-age=1800
EXT: 
ST: urn:schemas-upnp-org:device:MediaServer:1
USN: uuid:fa095ecc-e13e-40e7-8e6c-3431c480a9b4::urn:schemas-upnp-org:device:MediaServer:1

As farr as I understand this, looks OK.

CC: (none) => herman.viaene
Whiteboard: (none) => MGA7-64-OK

Comment 4 Thomas Andrews 2020-07-29 02:39:03 CEST
Validating. Advisory in Comment 2.

CC: (none) => andrewsfarm, sysadmin-bugs
Keywords: (none) => validated_update

Dave Hodgins 2020-07-31 11:41:05 CEST

CC: (none) => davidwhodgins
Keywords: (none) => advisory

Comment 5 Mageia Robot 2020-08-01 01:27:59 CEST
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2020-0304.html

Resolution: (none) => FIXED
Status: ASSIGNED => RESOLVED

Comment 6 Len Lawrence 2021-06-28 14:49:13 CEST
mga8, x86_64

Before updating checked out rygel which on launch performs an autonomous search through the user's directories for music, video and picture files to be shared on different networks.

Updated the packages.

Ran rygel under strace and let it run the harvesting process.
It hangs after that.  Launched Rygel preferences from the system tools menu.
The user's multimedia directories were registered in one panel of the gui.  Below that was the networks panel, waiting for input.  Have to pass on that.
The trace showed:
openat(AT_FDCWD, "/lib64/libgupnp-1.2.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libgupnp-av-1.0.so.2", O_RDONLY|O_CLOEXEC) = 26
openat(AT_FDCWD, "/lib64/libgupnp-dlna-2.0.so.3", O_RDONLY|O_CLOEXEC) = 30
openat(AT_FDCWD, "/usr/share/gupnp-dlna-2.0/dlna-profiles", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)

Good enough.

CC: (none) => tarazed25


Note You need to log in before you can comment on or make changes to this bug.