Wazuh
cpe:2.3:a:wazuh:wazuh:*:*:*:*:*:*:*
- >= 4.8.0, < 4.14.4
A stack-based buffer overflow vulnerability has been identified in Wazuh versions 4.8.0 prior to 4.14.4. The issue arises in the 'print_hex_string()' function of 'wazuh-remoted', where attacker-controlled bytes are formatted using 'sprintf' in a manner that can lead to an out-of-bounds write. This vulnerability is triggered on platforms that treat 'char' as signed, allowing bytes like 0xFF to be improperly formatted and cause a buffer overflow past a fixed 2049-byte stack buffer. The vulnerability can be exploited remotely, without authentication, through TCP port 1514, by sending an oversized message that triggers the vulnerable diagnostic path. Additionally, this path logs an attacker-controlled hex dump to 'ossec.log', creating a log amplification effect that can disrupt normal monitoring and consume system resources.
Exploitation of this vulnerability causes a stack-based buffer overflow, leading to an out-of-bounds write on the stack. While the vulnerability has not been demonstrated to reliably crash the application or hijack control flow in the shipping build, it has been confirmed to cause a deterministic out-of-bounds write, which could potentially be exploited to overwrite stack memory and manipulate the program's execution. Furthermore, the vulnerability allows for unauthenticated log amplification, where repeated triggers of the vulnerable diagnostic path can exhaust system resources and create noise in the alerting system.
The vulnerability can be reproduced by sending an oversized message over TCP port 1514 to a Wazuh manager running a vulnerable version. This can be done using a Python script that sends the crafted message, taking advantage of the 'print_hex_string()' function's vulnerability to create a buffer overflow. The exploitation can be verified by observing the AddressSanitizer's report of a stack-buffer-overflow error, which indicates that the overflow has occurred as expected.
Users can upgrade to Wazuh version 4.14.4 or later, where this vulnerability has been patched.
Our algorithm analyzes dozens of metrics to generate these 8 key vulnerability categories, which are then combined to calculate the overall risk score.