Skip to main content
OneCon26: Gain the advantage in the AI era. Oct. 20–22 in Las Vegas.Register Now
Vulnerability Database/CVE-2024-3049

CVE-2024-3049: Clusterlabs Booth HMAC Bypass Vulnerability

CVE-2024-3049 is an authentication bypass flaw in Clusterlabs Booth that allows invalid HMAC values to be accepted by the server. This post explains its impact, affected versions, and mitigation steps.

Published:

CVE-2024-3049 Overview

CVE-2024-3049 affects Booth, the cluster ticket manager developed by ClusterLabs and used to coordinate high-availability decisions across geographically distributed Pacemaker clusters. The flaw resides in how Booth validates Hash-based Message Authentication Codes (HMACs) using gcry_md_get_algo_dlen(). A specially crafted hash can cause the Booth server to accept an invalid HMAC, undermining the integrity guarantees of authenticated cluster messages. The weakness is classified under [CWE-345] (Insufficient Verification of Data Authenticity). Red Hat Enterprise Linux 7, 8, and 9, along with Debian and Fedora distributions that ship Booth, are affected.

Critical Impact

An attacker able to reach a Booth server over the network can forge authentication data, allowing invalid HMAC-protected messages to be accepted and potentially influencing cluster ticket decisions.

Affected Products

  • ClusterLabs Booth (upstream cluster ticket manager)
  • Red Hat Enterprise Linux 7, 8, and 9 (including EUS variants for ARM64, IBM Z, and Power little-endian)
  • Red Hat Enterprise Linux Server Update Services for SAP Solutions 8.4

Discovery Timeline

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

Technical Details for CVE-2024-3049

Vulnerability Analysis

Booth arbitrates cluster tickets between sites and relies on HMAC verification to authenticate messages exchanged between Booth arbitrators and participating clusters. The vulnerable code path calls gcry_md_get_algo_dlen() on a hash algorithm identifier taken from an incoming message. When a specially crafted hash value is supplied, the length calculation and subsequent comparison logic can permit an invalid HMAC to be accepted as valid.

The classification under [CWE-345] reflects that the server fails to sufficiently verify the authenticity of data it processes. Successful exploitation compromises the integrity of ticket-granting decisions in geo-clusters, where Booth is the authoritative decision-maker for failover between sites.

Root Cause

The root cause lies in Booth's handling of the digest length returned by libgcrypt's gcry_md_get_algo_dlen() API. Booth did not sufficiently validate the algorithm identifier or the resulting length before performing the HMAC comparison. As a result, an attacker-controlled hash field could steer the code into a state where the comparison passes for an HMAC that does not match the expected value. The upstream fix is tracked in ClusterLabs Booth pull request #142.

Attack Vector

The attack is network-based and requires no authentication or user interaction, but the attack complexity is high because the attacker must craft the hash field in a way that triggers the flawed length handling and defeats the HMAC comparison. An attacker with network reach to the Booth service (typically TCP/UDP 9929) can send forged messages that the server accepts as authentic. Impact is limited to integrity: confidentiality and availability are not directly affected, but forged ticket-related messages can influence cluster arbitration decisions.

No public proof-of-concept exploit is available, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. See the Red Hat CVE-2024-3049 advisory and Red Hat Bugzilla #2272082 for additional technical context.

Detection Methods for CVE-2024-3049

Indicators of Compromise

  • Unexpected Booth ticket state transitions or arbitration decisions that do not correlate with legitimate cluster events.
  • Booth log entries showing accepted messages from source addresses outside the documented arbitrator and site membership.
  • Repeated malformed or unusually structured HMAC-bearing packets on the Booth port (default 9929) preceding a ticket change.

Detection Strategies

  • Inventory all hosts running the booth package and compare installed versions against the fixed versions listed in the applicable Red Hat, Debian, and Fedora advisories.
  • Monitor Booth daemon logs (/var/log/messages, journalctl -u booth) for authentication or HMAC verification anomalies and unexpected peer addresses.
  • Correlate Pacemaker cluster ticket events with Booth peer traffic to identify arbitration decisions that lack a corresponding legitimate trigger.

Monitoring Recommendations

  • Capture and baseline network flows to Booth ports so that connections from non-arbitrator hosts are alerted on.
  • Forward Booth and Pacemaker logs to a centralized logging or SIEM platform for long-term retention and cross-site correlation.
  • Track package versions of booth-core, booth-arbitrator, and booth-site in configuration management to detect drift from patched baselines.

How to Mitigate CVE-2024-3049

Immediate Actions Required

  • Apply the vendor-supplied Booth updates on all arbitrator and site nodes in every geo-cluster deployment.
  • Restrict network access to Booth ports so that only known arbitrator and cluster peers can connect, using host firewalls or network ACLs.
  • Audit Booth authentication key files (authfile) to ensure they are still confidential and rotate them if exposure is suspected.

Patch Information

Red Hat has released fixed Booth packages through advisories RHSA-2024:3657, RHSA-2024:3658, RHSA-2024:3659, RHSA-2024:3660, RHSA-2024:3661, RHSA-2024:4400, and RHSA-2024:4411. Debian users should follow the Debian LTS announcement from September 2024, and Fedora users should apply updates from the Fedora package announcement and its follow-up update. The upstream code fix is available in ClusterLabs Booth pull request #142.

Workarounds

  • Confine Booth traffic to a dedicated management VLAN or IPsec/VPN tunnel between geo-cluster sites so that untrusted networks cannot reach the service.
  • Enforce strict firewall rules limiting inbound connections to the Booth port to the explicit list of arbitrator and site IP addresses.
  • Where patching must be delayed, increase monitoring of Booth logs and ticket state changes to detect unexpected arbitration events quickly.
bash
# Example firewall restriction limiting Booth (port 9929) to known peers
firewall-cmd --permanent --zone=public --add-rich-rule='\
  rule family="ipv4" source address="192.0.2.10/32" \
  port port="9929" protocol="tcp" accept'
firewall-cmd --permanent --zone=public --add-rich-rule='\
  rule family="ipv4" source address="192.0.2.10/32" \
  port port="9929" protocol="udp" accept'
firewall-cmd --reload

# Verify installed Booth version after patching
rpm -q booth-core booth-arbitrator booth-site

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

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.

Try SentinelOne