Desktop Vulnerabilities in the Year of the Linux Desktop?

Posted on 29 January 2025 by Dimitris Glynos

In 2024, Linux built significant momentum in the desktop market, reaching a 4.55% market share in August 2024 according to statcounter statistics. It might not have been “the Year of the Linux desktop”, but there’s certainly an increase in users depending on Linux Desktop functionalities for work and personal activities.

For many years now, the Linux desktop has been the desktop of choice for mostly systems administrators, developers, researchers, students and hobbyists. In recent years it has gained some adoption in the public sector too, and is now also making moves in the circles of gamers (see 2% market share reported by Steam in July 2024). The combined user group of systems administrators, public servants, developers and (to some extent) researchers, handles sensitive data (e.g. Confidential Business Data, Personally Identifiable Information, Intellectual Property) and sensitive processes (e.g. Operations that are key for the business of an organization) within its daily routine. The integrity of their workstation environment is therefore of paramount importance, as a compromise of their desktop would expose all of the aforementioned assets to unauthorized individuals.

A typical Linux Desktop consists of a collection of applications, libraries, and services, developed as open source software by contributors from around the world. Some of these developers may be contributing code as a hobby, while others as part of their work. It is the goal of Desktop Environment projects, such as GNOME and KDE, to bring together such desktop software projects, facilitate their interaction, cater for common functionalities and themes, improve the user experience and ultimately, user productivity.

Figure 1. Depiction of a GNOME 47 desktop. Source: gnome.org

Orchestrating this type of distributed development, and funding this through donations is no easy task, as evident by the financial sustainability remarks made in a recent GNOME board memo. Nevertheless, the Linux Desktop is growing also in maturity and it comes as no surprise that there is now more concern about vulnerabilities affecting Linux Desktop systems. Desktop vulnerabilities have routinely been exploited by attackers in the equivalent proprietary desktop environments, such as Microsoft Windows and Apple MacOS, during the course of so called client-side attacks. In client-side attacks adversaries gain a foothold into a victim organization by exploiting vulnerabilities in user workstations (or coercing users into performing malicious actions), thus bypassing any security perimeter defenses the organization might have set up.

Figure 2. Example scenario of a client-side attack where the attacker sends a malicious email to the victim user, bypassing any firewall protections.

Back in September 2024, a set of print-server related vulnerabilities were published by security researcher Simone Margaritelli that could allow for the remote execution of malicious code on vulnerable Linux Desktops. Exploitation required network access to the vulnerable service, a requirement that somewhat limited the attacker’s capabilities against a desktop system (which is typically situated behind a firewall). However, on server equipment, with print servers exposed to the Internet, exploitation of these vulnerabilities would have been catastrophic.

This is reminiscent of multiple print spooler vulnerabilities that have affected Microsoft Windows desktops in the past, including CVE-2021-34527.

In June 2024 Dimitris Glynos of intWave found that applications utilizing the GTK+3 (or GTK+2) library, allowed for remote code execution through a “drive by download” attack. When such applications could not locate a GTK module (another library) in the standard paths, they searched for the missing module in the Current Working Directory (CWD), which may contain untrusted resources, as is the case for the Downloads folder. The GTK project, where the issue was found, is the default graphics toolkit for GNOME Desktop applications and thus the issue affects the vast majority of GNOME Desktop applications. The issue is tracked as CVE-2024-6655 at NVD, and a high risk score was assigned by Red Hat, based on CVSS 3.1 metrics.

This vulnerability is reminiscent of the DLL Hijacking issues affecting Microsoft Windows applications, caused by the DLL search order. Palo Alto Networks reports that the technique of placing a malicious DLL in a certain location, to be later loaded by a certain legitimate application, is being actively abused by Advanced Persistent Threat (APT) groups in the wild.

Figure 3. DLL hijacking via drive-by-download attack.

But how exploitable was the GTK vulnerability? Could a remote attacker force a system to miss a library? Were there systems that were missing libraries by default?

Figure 4. Some example ways of meeting the requirements for the exploitation of CVE-2024-6655.

intWave found that in certain environments, GTK+3 applications were forced to look for a non-existent GTK module. In the case of Debian and Debian-derived Linux distributions (such as Ubuntu), an environment variable was forcing the loading of a module related to accessibility services, but the module was missing in GTK+3. During the reporting of the issue the developers of GTK mentioned that the environment variable feature was not meant to be used in this way, and that it was designed “for the loading of GTK modules for debugging purposes”.

Another problematic scenario is that of applications that come bundled with an affected version of GTK+3 and which are running as part of GNOME in an X11 environment. There, the GTK+3 applications are again searching for a missing module and an attacker could abuse this fact to execute malicious code. This attack vector remains true for many applications provided through an AppImage bundle, including the Inkscape version 1.4 bundle with MD5 sum 0d3807e6f2f732422ea56d076dcaa6eb. It is interesting to note that an open source project may choose not to bump the project version number for such a packaging fix, as the fix concerns the packaging and not some version of the source code of the software.

Although major Linux distributions like Debian and Ubuntu pushed an updated version of the GTK+3 (and GTK+2) shared library, the problem still persists for applications that come bundled with a vulnerable version of the library (such as the Inkscape AppImage example described above). There it is the responsibility of the project to take notice of the issue and repackage / rebuild their application as appropriate. Due to the voluntary nature of the open source ecosystem it seems there is currently no better alternative for users than to prefer the distribution-provided version of an application. However, please note that if the bug had been found in shared Rust or Go code, distributions providing binary packages would have still needed to rebuild and redistribute all affected Rust/Go applications (severely increasing the bytes transferred over the network for a security update).

More information about CVE-2024-6655, along with videos of proof-of-concept exploitation can be found in the intWave advisory article.

In conclusion, as the Linux Desktop matures and is used by more and more organizations handling sensitive data and sensitive processes, it is understandable that concerns regarding the state of security of the Linux Desktop will be growing. In this article we drew parallels between vulnerabilities that have affected proprietary Desktop environments and equivalent vulnerabilities in open source Linux Desktop environments, describing how these could be abused by malicious actors to compromise desktop systems. Finding and fixing such vulnerabilities across the open source ecosystem is a non-trivial task. It is clear that investment and orchestration efforts are needed to address this problem at scale.