I reviewed gssdp 1.2.0-1 as checked in to eoan. This isn't a full security audit, but rather a quick gauge of maintainability.
- gsspd is a gobject based library for using SSDP (Simple Service Discovery Protocol), and is required by rygel. - gssdp is part of the GNOME project. - It doesn't see a lot of git activity, but it's quite a small project so that's not really unexpected. - No CVEs in our database. - Build dependencies in main except for gnome-pkg-tools, meson and valac - none of which create binary dependencies. - Doesn't spawn any subprocesses. - Looks like it's careful with memory management. - No logging other than a few g_debugs (which are off by default). - Doesn't use the environment - No privileged code. - Does some networking: - Consumers of the gssdp API create a GSSDPClient for each network interface. - GSSDPClient sets up 3 sockets - IIUC, the first one receives SSDP (NOTIFY and M-SEARCH) multicast packets. The second one is for sending SSDP NOTIFY multicast packets and sending responses to SSDP M-SEARCH multicast queries. The third one is for sending SSDP M-SEARCH multicast queries and receiving responses to those. - The first socket is bound to the SSDP multicast address and port. - The second socket is bound to the interface address and SSDP port. - The third socket is bound to the interface address and a random port. - Unless I've misunderstood something, the way that the sockets are configured seems a bit weird and I think there might be a bug. The IP_MULTICAST_IF sockopt is set (via gssdp_socket_mcast_interface_set) and IP_ADD_MEMBERSHIP is set (via g_socket_join_multicast_group) on the same socket - the one that receives multicast packets. Shouldn't the IP_MULTICAST_IF sockopt be set on the other 2 sockets (the ones sending multicast packets) instead? - It's using AF_NETLINK for looking up MAC addresses, which it uses for keying a hashtable of cached user agent strings from other devices. - The max-age in alive announcements is set to 1800s. Re-announcements are sent 3 times during this period. - It responds to unicast M-SEARCH queries, which is called out in https://blog.cloudflare.com/ssdp-100gbps/. Devices that respond to unicast M-SEARCH queries and are directly connected to the internet can be used in DDoS attacks in scenarios where an attacker is able to generate packets with a spoofed source IP. It does employ some rate limiting though - it delays the response by a random time of between 0 and 3 seconds. This was tested with netcat. - No crypto. - No sql. - No privileged commands. - Doesn't use any environment variables. - No webkit. - Lintian clean, other than a warning about there being no manpage for /usr/bin/gssdp-device-sniffer - A single binary - /usr/bin/gssdp-device-sniffer in gssdp-tools, which provides a UI for monitoring SSDP announcements. - Build logs look clean other than some doc warnings. - No configuration files. - No systemd services. - No dbus services. - No setuid binaries. - No fs capabilities. - No sudo fragments. - No udev rules. - No cron jobs. Security team ACK for promoting gssdp to main. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1799977 Title: [MIR] gssdp To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gssdp/+bug/1799977/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
