[P.Raveendra Reddy]

NET-SNMP is a service listening on a UDP port which provides useful information to administrators related to the network, the CPU activity or the memory currently used. It is usually polled in order to perform various sanity checks using home made scripts. Access to this service is restricted using a community secret (v1 and v2c of the protocol) or a more complex authentication process (v3).

The version 5.7.2 was vulnerable to a heap corruption within the parsing of the PDU prior to the authentication process.

Details given in the attached document

All,
Looks like this is fixed as part https://sourceforge.net/p/net-snmp/code/ci/f23bcd3ac6ddee5d0a48f9703007ccc738914791/

will apply the patch and get back.

I agree that it's fixed. Did you have any luck testing it?

marked as private

Yes. verfied. so closing the defect. Please close the bug.

Hi
I use SilverCreek and I was asked to create a test to verify this has been fixed.
I did read the related code and see the issue should have been fixed.
But I could not find a way to verify the fix.

I used NET-SNMP 5.4 and 5.7.3 to test. I could not cause to agent under test to crash (denial of service)
by creating a tampered request that does what you suggested in your document (quoted below):

---

Whenever snmpparsevarop() fails, the last variable will remain within the list,
partially initialized. Practically speaking, it is easy for an attacker to
generate such a behavior. One could, for example, tamper with the ASN1 tag to
have a value different than (ASNSEQUENCE |
ASNCONSTRUCTOR) and the function would immediately return as illustrated below:
…

---

sudo /usr/sbin/snmpd -L ~/mylog.txt -d 0.0.0.0:161
Frst, a well formted snmpset request with three variable bindings were sent to the DUT:

Received 77 bytes from UDP: [192.168.137.210]:32784
0000: 30 4B 02 01 01 04 07 70 72 69 76 61 74 65 A3 3D 0K.....private.=
0016: 02 01 26 02 01 00 02 01 00 30 32 30 0F 06 08 2B ..&......020...+
0032: 06 01 02 01 01 04 00 04 03 61 61 61 30 0E 06 08 .........aaa0...
0048: 2B 06 01 02 01 01 06 00 04 02 49 4C 30 0F 06 0A +.........IL0...
0064: 2B 06 01 02 01 02 02 01 08 01 02 01 01 +............

Connection from UDP: [192.168.137.210]:32784
Received SNMP packet(s) from UDP: [192.168.137.210]:32784
SET message
-- SNMPv2-MIB::sysContact.0
-- SNMPv2-MIB::sysLocation.0
-- IF-MIB::ifOperStatus.1

To test, I changed the sequence of the second variable binding

{sysLocation.0 IL}

From 30 to 00, as shown below:

30 0E 06 08 2B 06 01 02 01 01 06 00 04 02 49 4C

to

00 0E 06 08 2B 06 01 02 01 01 06 00 04 02 49 4C

Request captured on wire:
Received 77 bytes from UDP: [192.168.137.210]:32784
0000: 30 4B 02 01 01 04 07 70 72 69 76 61 74 65 A3 3D 0K.....private.=
0016: 02 01 26 02 01 00 02 01 00 30 32 30 0F 06 08 2B ..&......020...+
0032: 06 01 02 01 01 04 00 04 03 61 61 61 00 0E 06 08 .........aaa....
0048: 2B 06 01 02 01 01 06 00 04 02 49 4C 30 0F 06 0A +.........IL0...
0064: 2B 06 01 02 01 02 02 01 08 01 02 01 01 +............

Connection from UDP: [192.168.137.210]:32784
Received SNMP packet(s) from UDP: [192.168.137.210]:32784

or to 0E as below:
0E 0E 06 08 2B 06 01 02 01 01 06 00 04 02 49 4C

Request captured on wire:
Received 77 bytes from UDP: [192.168.137.210]:32784
0000: 30 4B 02 01 01 04 07 70 72 69 76 61 74 65 A3 3D 0K.....private.=
0016: 02 01 26 02 01 00 02 01 00 30 32 30 0F 06 08 2B ..&......020...+
0032: 06 01 02 01 01 04 00 04 03 61 61 61 0E 0E 06 08 .........aaa....
0048: 2B 06 01 02 01 01 06 00 04 02 49 4C 30 0F 06 0A +.........IL0...
0064: 2B 06 01 02 01 02 02 01 08 01 02 01 01 +............

But still it does not cause the DUT to crash.

Could you let me know how did you exploit this bug to crash the affected agent ? Thank you in advance.

Thanks in advance.

-Xiang Li

The original bug report for this issue https://sourceforge.net/p/net-snmp/bugs/2615/ has a couple of .pcap files attached; those might help you determine the sequence of bytes that he used to show the issue.

Thanks Bill for the pointer. Unfortunately I looked these two cap files but it appears that none of SNMP requests contained there can actually trigger a crash. it is likely that the original person who reported this was working on a customized version of net-snmp. For example, a snmp-get without any variable bindings got a report from the agnet with 9 variable bindings (packet_eth0_0a3_2.pcap). I don't think the original net-snmp does that.

I quickly glanced the related source code, it appears that although the code before patching was not doing cleanup properly it should not cause agent to crash. Since any request received by the agent that failed during snmp_pdu_parsing will be thrown out and not used in any later processing. I don't see an easy way to cause the denial of service by exploiting this bug,

I might be wrong but let's see if P.Raveendra Reddy has any comments on reproducing the crash here.
Best regards,
-Xiang

I wrote the "snmppcap" code that you find in apps/ for the purpose of evaluating user-submitted packet captures, and unless I am remembering wrong, at least one of the pcap's attached to that report caused a crash due to a NULL pointer - but this is the client behavior, e.g., "snmpget" against a malicious server could crash.

Re-reading my notes, we asked the original reporter a few times how to get the server to crash and he was at best cagy, and said that he could not make it crash. Based on the fact that it's a malformed varbind list, and it appears to require accessing the value, I believe that the only code path that the server will take that does this is the already-authenticated SET request path: meaning, if there is any vulnerability in the server, it is to a user who has write access sending a malformed SET. (And, I guess that's a hint for your replication attempt: create an rw user and have it send a SET with a malformed varbind list)

The "get with no varbinds -> report" sequence that you're talking about sounds like SNMPv3 engine-ID discovery.

I am only interested in finding a way to exploit this bug to cause DOS on the snmpd server side, not snmpget client.

I already tried to SET, in addition to GET/NEXT using malformed variable bindings, although what I did is for SNMPv1 and SNMP V2c SET. I would think V3 code uses the same code for parsing variable bindings but I am not sure (I may come back to check this later).

For SNMP engineID discovery, I believe NET-SNMP agent will send back a report with the usmStatsUnknownEngineIDs counter in the varBindList, NOT those 9 variable bindings in the original report's capture file.
Best regards,

-Xiang

I am also interested in finding a way to exploit this bug to cause DOS on the snmpd server. The original reporter was unable to; as far as I can tell the report in this bug hasn't done anything other than describe the fact that the return value is incorrect and not explored the ramifications.

You're right that the varbind parsing should be the same for v1/v2c/v3.

I'm sorry for my fuzzy thinking earlier - of course given that the only demonstrated vulnerability is of snmpget parsing a bad return value, the packet capture must be against a "funny" server.

This is a duplicate of #2615, which was CVE-2015-5621.

If this is a duplicate of CVE-2015-5621, then CVE-2018-1000116 has to be rejected. We cannot have two CVEs for one vulnerability.

Who has authority to reject a CVE? As far as I know, anyone can get a CVE number and claim anything using it.