CVE-2024-45339

What it actually does

In glog, when the default log directory is world-writable, an attacker can predict the log file path of a privileged process and pre-create a symlink pointing to a sensitive target file; the privileged process then follows the symlink and overwrites the target.

Why it matters to the business

Privileged processes using affected logging can be tricked into destroying or corrupting critical system files, leading to denial of service, configuration loss, or privilege escalation on affected Red Hat OpenShift coreos-installer deployments.

How an attack unfolds

An attacker with local access enumerates the predictable log path, creates a symlink to a sensitive file such as /etc/shadow or a configuration file, waits for the privileged process to start logging, and causes the process to follow the symlink and overwrite the target file.

How to fix it

Upgrade coreos-installer, coreos-installer-bootinfra, coreos-installer-bootinfra-debuginfo, coreos-installer-debuginfo, and coreos-installer-debugsource packages on Red Hat OpenShift 4.9 to version 0:0.10.1-1.rhaos4.9.el8 or later; restrict log directory permissions to prevent world-writable access.

How to confirm the fix worked

Verify installed package versions match or exceed the fixed releases, confirm that glog now exits with status 2 when a log file path already exists, and test that no symlink can be followed during log initialization.

Typical attack path

1. Identify a world-writable directory used for logs by the target process
2. Predict the exact log file path the privileged process will create
3. Pre-create a symlink at that path pointing to a sensitive target file
4. Trigger or wait for the privileged process to initialize logging
5. Observe or confirm that the sensitive target file has been overwritten

How to detect it

Search system and application logs for unexpected exits with status code 2 mentioning existing log files, inspect for symlinks in log directories that point outside expected paths, and review file modification timestamps on sensitive targets that coincide with log initialization times.

What your security team should do

• Immediately schedule upgrades to the fixed package versions listed for each affected coreos-installer component
• Audit and tighten permissions on any directories used for application or system logs
• Monitor for processes unexpectedly exiting with status code 2 related to log file conflicts
• Review privileged services that rely on glog for logging and apply least-privilege directory controls