Skip to main content
Vulnerability Database/CVE-2024-34477

CVE-2024-34477: FOG Project Privilege Escalation Vulnerability

CVE-2024-34477 is a privilege escalation vulnerability in FOG Project affecting versions through 1.5.10. Attackers can exploit insecure NFS configurations to gain root privileges. This article covers technical details, affected versions, security impact, and mitigation strategies.

Published:

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Sources: National Vulnerability Database, CISA KEV, Exploit-DB

CVE-2024-34477 Overview

CVE-2024-34477 is a local privilege escalation vulnerability in FOG Project versions through 1.5.10. The flaw resides in the configureNFS function within lib/common/functions.sh, which exports Network File System (NFS) shares with insecure options including no_root_squash and insecure. These options allow local users to mount a crafted NFS share, place a root-owned executable with the SUID bit set, and execute it to gain root privileges on the host. The vulnerability is tracked under CWE-250: Execution with Unnecessary Privileges and affects the imaging and cloning solution widely deployed in educational and enterprise environments.

Critical Impact

Authenticated local users can escalate to root by abusing the FOG NFS export configuration to drop and execute SUID binaries owned by root.

Affected Products

  • FOG Project versions up to and including 1.5.10
  • Installations exposing the default FOG NFS exports configured by configureNFS in lib/common/functions.sh
  • Linux hosts running the FOG server with the vulnerable /etc/exports entries

Discovery Timeline

  • 2024-05-27 - CVE-2024-34477 published to the National Vulnerability Database
  • 2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-34477

Vulnerability Analysis

FOG Project is an open-source cloning and imaging solution that relies on NFS to transfer image data between the server and client workstations. During installation, the configureNFS routine in lib/common/functions.sh writes /etc/exports entries that share FOG image directories with the no_root_squash and insecure options enabled. The no_root_squash option disables the standard squashing of remote UID 0 to the unprivileged nobody account, which means a client connecting as root retains root privileges when writing files to the exported share. The insecure option permits NFS requests originating from ports above 1024, lowering the barrier to connect from an unprivileged client. Combined, these settings grant any local user who can reach the NFS service the ability to stage a root-owned, SUID-marked binary on the server's filesystem.

Root Cause

The root cause is the configureNFS function configuring NFS exports with excessive privileges, violating the principle of least privilege described in CWE-250. The affected export line can be reviewed in the FOG Project source on GitHub. The exported directories must be writable by the FOG service for imaging operations, but combining write access with no_root_squash eliminates the kernel-level separation between remote clients and local root identity.

Attack Vector

An attacker with a local account on a network-reachable host mounts the FOG NFS share using an NFS client. Because no_root_squash is in effect, the attacker writes a file as UID 0, chowns it to root, and sets the SUID bit, for example on a copy of /bin/bash or a custom wrapper that spawns a shell. The attacker then executes that binary on the FOG server (or another host that mounts the same share) through legitimate access. The SUID bit causes the binary to run as root, yielding full system compromise. See the Hackvens advisory for CVE-2024-34477 and the FOG Project forum discussion for the full exploitation walkthrough.

Detection Methods for CVE-2024-34477

Indicators of Compromise

  • Entries in /etc/exports on the FOG server containing both no_root_squash and insecure options for FOG-managed directories.
  • New SUID root binaries appearing in FOG image or storage directories such as /images, /images/dev, or /opt/fog.
  • Unexpected shell processes spawned by users whose parent process chain traces back to a binary stored on an NFS-exported FOG path.

Detection Strategies

  • Audit /etc/exports and the output of exportfs -v on FOG servers for the vulnerable export flags.
  • Scan FOG storage directories periodically with find /images /opt/fog -perm -4000 -user root to enumerate root-owned SUID files.
  • Monitor NFS mount activity from unexpected client IP addresses, especially mounts followed by writes of ELF binaries.

Monitoring Recommendations

  • Enable Linux auditd rules on the FOG server to log chmod operations that set the SUID bit (-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F a1&04000).
  • Forward FOG server syslog, auditd, and NFS server logs to a centralized analytics platform for correlation of mount, write, and execution events.
  • Alert on execution of binaries located under FOG image paths from non-service user contexts.

How to Mitigate CVE-2024-34477

Immediate Actions Required

  • Upgrade FOG Project to a release that corrects the configureNFS function; track remediation status in the FOG Project forum advisory.
  • Remove no_root_squash and insecure from /etc/exports entries for FOG shares and re-export with exportfs -ra.
  • Enumerate and remove unauthorized SUID root binaries placed in FOG storage directories.

Patch Information

The vendor coordinates fix guidance through the FOG Project forum thread for the 1.5.10 NFS privilege escalation. Administrators should update FOG to the latest version beyond 1.5.10 that modifies configureNFS in lib/common/functions.sh to use safer export options, and verify the resulting /etc/exports content after upgrade.

Workarounds

  • Replace no_root_squash with root_squash on all FOG NFS exports so remote root is mapped to an unprivileged account.
  • Restrict NFS exports to specific trusted client subnets or hostnames rather than wildcard entries.
  • Mount FOG storage filesystems with the nosuid option so SUID bits on files stored there are ignored at execution time.
bash
# Example hardened /etc/exports entry for a FOG image share
/images  10.0.0.0/24(rw,sync,root_squash,secure,no_subtree_check)
/images/dev  10.0.0.0/24(rw,sync,root_squash,secure,no_subtree_check)

# Apply the new export table
sudo exportfs -ra

# Mount FOG storage with nosuid to neutralize staged SUID binaries
# /etc/fstab entry
# UUID=<uuid>  /images  ext4  defaults,nosuid,nodev  0  2

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Sources: National Vulnerability Database, CISA KEV, Exploit-DB

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.