Security flaws in how software handles log files are surprisingly common. One such vulnerability, CVE-2024-45339, was discovered in the popular C++ logging library glog. In this guide, we'll break down what CVE-2024-45339 is, show how attackers can exploit it using symbolic links (symlinks), provide code snippets to explain the issue, walk through a basic exploit scenario, and explain how the vulnerability has been fixed — all in simple language so anyone can understand.

The Basics: What is CVE-2024-45339?

Many applications, especially those running with high privileges, write log files to disk. If these log files are saved in directories that ordinary users can write to (like /tmp), it opens the door for a classic attack: symlink attacks.

> CVE-2024-45339 is a vulnerability in glog where an attacker can predict the log file name and pre-create a symbolic link with that name, pointing to a file they want to overwrite (such as /etc/passwd). When a privileged program starts, it writes its logs and unintentionally overwrites the sensitive file _instead_, potentially leading to major security problems.

Reference

- CVE-2024-45339 entry on NIST
- glog Security Advisory GHSA-4qgp-36hw-7gmg

Here’s a simple sequence to demonstrate the problem

1. An application is running as root and uses glog to create logs in /tmp.
2. An attacker can predict the log file’s path (because glog log file names are based on process name, time, etc).
3. The attacker creates a symlink in /tmp with the predicted log file name, but the symlink points to a critical file such as /etc/shadow.
4. When the app starts, it opens the log file for writing (following the symlink), and ends up overwriting /etc/shadow.

This attack works because glog didn’t check if the destination is a symlink or already exists before opening it.

Code Snippet: Simulating the Exploit

Let's look at a simple C++ example of logging, but the principle is the same for any glog-using program:

#include <glog/logging.h>
#include <unistd.h>

int main(int argc, char* argv[]) {
    google::InitGoogleLogging(argv[]);
    FLAGS_log_dir = "/tmp";  // The dangerous default!
    LOG(INFO) << "Logging something highly privileged";
    return ;
}

If this runs as root, its log file will go into /tmp by default.

Now, an attacker (as an unprivileged user) can do this

# Predict what the log file will be called, glog uses "<program>.<hostname>.<user>.log.<pid>"
# For example, "myapp.hostname.root.log.12345"

ln -s /etc/shadow /tmp/myapp.hostname.root.log.12345

When the program above runs, it tries to write to /tmp/myapp.hostname.root.log.12345 — but that’s a symlink to /etc/shadow. Now /etc/shadow gets clobbered by log entries. Oops.

In-Depth: Why Did This Happen?

- Predictable log file names: glog’s log file format is easy to guess, especially if you control process name and environment.
- Default writable log directory: Many distros or sample code set FLAGS_log_dir to /tmp where all users can write.
- No pre-existence or symlink check: Before the fix, glog would open (and potentially create or clobber) any file given as its log path.

- Use the ln -s command to link your target sensitive file (like /etc/shadow or a user’s .ssh/authorized_keys) to the predicted log file path.

Check the Target File

- If the attack worked, /etc/shadow has now been overwritten with logs (possibly breaking the system, or allowing later exploits).

After the vulnerability was reported, glog developers released a patch. The new behavior is

> If the log file _already exists_ (whether regular file or symlink), glog now exits with status code 2 without writing anything.

This means an attacker can no longer use symlinks to redirect where logs are written — if their symlink is there first, the program just refuses to run. Here’s the relevant PR.

Upgrade glog: Make sure you use glog version .7. or higher, which contains the fix.

- glog releases
- Never log to writable directories like /tmp.

Set FLAGS_log_dir to a directory only accessible by your application.

- Check for vulnerable programs on your system: Look for root-running programs using glog set to log in /tmp or other public directories.

Example Safe Configuration

FLAGS_log_dir = "/var/log/myapp"; // Only root can write!

Make sure /var/log/myapp is owned by root and permissions are set

sudo mkdir -p /var/log/myapp
sudo chown root:root /var/log/myapp
sudo chmod 700 /var/log/myapp

Always keep third-party libraries like glog up to date.

- Don’t log to /tmp or other publicly writable locations!

References and Further Reading

- CVE-2024-45339 Details - NVD
- glog Security Advisory (GitHub)
- glog Pull Request #972 (the fix)
- Symlink Race Vulnerabilities Explained - OWASP

Final Notes

Vulnerabilities like CVE-2024-45339 are a great reminder: something as innocent as logging can result in serious security issues if you don't pay attention to file handling. Keep your dependencies up to date, and never write logs where attackers can plant files!

Timeline

Published on: 01/28/2025 02:15:28 UTC
Last modified on: 02/17/2025 11:15:08 UTC