Bug#1106527: gnome-remote-desktop: CVE-2025-5024: DoS via resource exhaustion

[Salvatore Bonaccorso]

Hi Simon,

On Thu, Jul 10, 2025 at 10:38:34AM +0100, Simon McVittie wrote:
> Control: retitle -1 gnome-remote-desktop: CVE-2025-5024: DoS via resource exhaustion
> Control: forwarded -1 https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/321
> 
> On Sun, 25 May 2025 at 16:13:13 +0200, Salvatore Bonaccorso forwarded:
> > | A flaw was found in gnome-remote-desktop. Once gnome-remote-desktop
> > | listens for RDP connections, an unauthenticated attacker can exhaust
> > | system resources and repeatedly crash the process. There may be a
> > | resource leak after many attacks, which will also result in gnome-
> > | remote-desktop no longer being able to open files even after it is
> > | restarted via systemd.
> 
> I don't think this is a showstopper for trixie: it allows an attacker on the
> local LAN to cause a denial of service via resource exhaustion, but it seems
> like it's only a denial of service and not something more serious, and it's
> only exploitable by an attacker who can contact the remote desktop server's
> RDP port. That's contrary to g-r-d's intended security model, hence a CVE,
> but I wouldn't want to expose a protocol as powerful as RDP onto untrusted
> networks *anyway*.
> 
> The typical use-case that I would expect for gnome-remote-desktop is that a
> Debian GNOME desktop system enables gnome-remote-desktop, and a client
> system on the same LAN (Debian or not, and GNOME or not) remote-controls
> that system via a RDP client.
> 
> A mitigation is to firewall the desktop system (firewalld or similar) so
> that RDP is only exposed when on a trusted or at least mostly-trusted WLAN,
> or to only enable gnome-remote-desktop temporarily when it is needed and
> disable it afterwards.
> 
> There is a merge request open upstream (linked above) but it hasn't been
> merged and has some known issues, and it's a significant code change (it
> adds a complete implementation of connection counting and throttling).

Thanks for this update. I have marked the issue as no-dsa in the
security-tracker, and agreed if you have fix for trixie which is ready
to go in and feel confident about it then good otherwise it should not
be a showstopper defintively.

Regards,
Salvatore