#1214 A buggy SNMPv3 agent can cause a net-snmp client to hang
We found this in net-snmp 5.4.3, but the code in 5.7.1 seems to have the same issue (I have attached a patch that should work for 5.7.1; I have only tested the patch in 5.4.3).
Basically, if a buggy SNMPv3 agent LIES about its EngineTime or EngineBoots values, then net-snmp will hang FOREVER on all get and walk commands (I didn't test set commands). What happens is that the agent will report a set of values for EngineTime and EngineBoots, but it will be reporting the WRONG values for what it has stored internally. SNMPv3 "discovery" will learn about those values and issue the request with them, but the agent will respond with an usmStatsNotInTimeWindows report (with those same values). net-snmp and the agent will go back and forth for a few retries until net-snmp will stop asking and WAIT FOREVER.
This appears to be due to the state-machine implementation of requests in which a usmStatsNotInTimeWindows response implies that "waiting" should be set to "1" since we will simply retry the request and everything will be great.
It DOESN'T respect the retries counter that slowly counts up to "sp->retries". When the retry counter gets that large, net-snmp SHOULD assume that it's screwed and set "waiting" to "0" so that it can fail the request attempt properly.
----
To reproduce this, you have to first "bug" net-snmp so that "snmpd" will always respond with bogus values of EngineBoots and EngineTimes. You can do this by updating the following two functions in snmpusm.c:
1. usm_generate_out_msg
2. usm_rgenerate_out_msg
What you need to do is find where "boots_long" and "time_long" are set to "boots_uint" and "time_uint", respectively, and set them to implausible constants, such as "9001" for "boots_long" and "8675309" for "time_long". You have to do this in BOTH functions.
After doing that, you will have a buggy snmpd that will never respond to an SNMPv3 request properly, and ALL of your SNMPv3 requests TO that agent will hang forever. The patch attached should address the problem.
----
As far as I can tell, this will apply to all versions of net-snmp.
This patch should fix the issue in 5.7.1
This patch is what we use in 5.4.3 to fix the problem.
moving to patches ...
Thanks for the patch! It has been applied to the 5.4.x and above code branches and the main development tree, and will appear in future releases of the Net-SNMP package.
Hi,
As far as I can tell, this patch causes a crash when SNMPv3 packets fail. There's simply no guarantee that “magic” points to a struct synch_state, so you end up overwriting a random value in the caller's address space.
In particular, I've seen this happen with the Perl module.