CVE-2014-3565

What it actually does

Crafted SNMP trap messages processed under the -OQ option trigger unsafe type conversion from the MIB definition, resulting in a NULL pointer dereference that crashes snmptrapd.

Why it matters to the business

Loss of SNMP trap collection interrupts network device monitoring, reducing operational visibility and potentially delaying incident response across environments that rely on net-snmp for alerting.

How an attack unfolds

An attacker sends a specially constructed SNMP trap containing a NULL-typed ifMtu variable; when snmptrapd receives and decodes the message using the -OQ output option, the MIB-driven type conversion fails and terminates the daemon.

How to fix it

Upgrade net-snmp to a version newer than 5.7.0, disable the -OQ command-line option where feasible, or apply vendor patches; restrict inbound SNMP traps to trusted sources via firewall or ACL rules.

How to confirm the fix worked

Confirm net-snmp version is newer than 5.7.0; attempt reproduction of the crash with a test trap containing a NULL-typed ifMtu variable under -OQ; verify absence of segmentation faults in snmptrapd logs after upgrade.

Typical attack path

1. Locate exposed snmptrapd listeners accepting traps from untrusted sources
2. Craft an SNMP trap message embedding a NULL type for an ifMtu variable
3. Transmit the trap to the target daemon
4. Observe crash of snmptrapd process

How to detect it

Search snmptrapd and system logs for abrupt process termination around receipt of ifMtu traps; inspect incoming SNMP packets for NULL-typed variables in trap PDUs.

• snmptrapd.*crash
• ifMtu.*NULL
• NULL type in trap message

What your security team should do

• Prioritize upgrade of all net-snmp installations older than 5.7.1
• Review and restrict SNMP trap sources to known management stations
• Monitor for repeated snmptrapd process restarts in system logs
• Test fallback monitoring paths to maintain visibility during outages