I did not report it to the upstream, but another vendor helped me to report it to the upstream and gave me the relevant CVE number. You can check the following link about netsnmp: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016139

@zoenan7 have you managed to report to upstream?

Alternatively, can you provide the contact information of NET-SNMP's PRIST? I can also contact him for vulnerability disclosure.

Yes, I also believe that this crash exists in all current versions of NET-SNMP. And I also found this vulnerability in the source code of the latest version of Net-SNMP( version 5.9.1), and I compiled and installed net-SNMP on Ubuntu to duplicate this vulnerability. But I can't find the contact information of NET-SNMP. It seems that only the cooperative manufacturer can contact him. Can you negotiate with them to disclose this vulnerability?

@zoenan7 Sorry for the late reply! Yes, I got your email and could reproduce the crash using your PoC.

@dmbaturin Did you get my email? If not, please let me know and I will send it again

By the way, the SNMPD service of the router will not restart automatically. After the SNMP service is attacked, the SNMP service cannot be restored even if the device is restarted, which may be an inappropriate implementation.

I have a question. If you confirm the existence of the vulnerability, can you report to the NET-SNMP vendor and apply for a CVE number?

I have sent the POC of the vulnerability to [email protected].

By the way, The password of the compressed package is HGkasjgJFYL261.

Hello, I have found three vulnerabilities in V1.2.7, one of which can also be reproduced in V1.3, please continue to check the other versions, I will send all three POCs to your email, thank you for your work.

@zoenan7 Thanks for your research! You can send the PoC to [email protected]

Submitted this PR: https://github.com/vyos/vyatta-op/pull/46

the possible completion output is fixed in the latest release: 1.4-rolling-202106151212

The question is if this is really relevant - as to my knowledge it is not possible to clear those counters unless unloading and reloading the interface driver(s)

thank you for the suggestion, I will work on this.

Maybe a completion helper could work here, too?

When the following command "set system syslog file <filename> facility <keyword> level <keyword>" is applied, then the files are stored in the /var/log/user directory. These files can be deleted using the command "delete log file <text>"

Looks good on 1.3-rolling-202104220921:

sudo journalctl -b