1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.DIST

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

    From Simon McVittie@21:1/5 to All on Thu Jul 10 11:50:01 2025
    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).

    smcv

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Salvatore Bonaccorso@21:1/5 to Simon McVittie on Thu Jul 10 20:50:01 2025
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)