First step would be to make the driver work. We would need to first know what "breaks" it. Best is to play around with the various command line options of the lcdproc client. As you mentioned, some client functions just call for characters, but others invoke big numbers, horizontal or vertical bars. These invoke a bit of contortion in the code involving swapping bitmaps for what is generally a very limited number of custom/graphic characters. Once we know what breaks, we can look into the best path forward for a code fix:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Wed, Nov 27
Sep 13 2024
Sep 11 2024
Update on current discoveries.
So pfSense has the same issue with garbage showing on the screen if I kill it's lcdproc_client.php process. That PHP script loads all the custom stats and writes them to the LCDd socket. But it only prints plain text which is why I assume it has no issues.
Aug 29 2024
Have you tried running the lcdproc client just for load average? It is just text. Maybe the more complex displays involving histograms, etc. are not working quite right.
Aug 23 2024
I messed around with it today, and made some progress!
Aug 21 2024
It looks like you are already running this with a high reporting level. Are you seeing any/all the messages on stderr? I would try all of this on the command line first, and do the VyOS cli later.
Aug 20 2024
Yeah I was running lcdproc in a separate window in the foreground as well, and restarted it each time I change a setting in LCDd
Aug 19 2024
I need to reopen the code from the lcdproc project as well as the platform package from Lanner and "compare".
The LCDd exit with code 1 was resolved by simply changing Driver=cwlnx to Driver=CwLnx
I now have an appliance to use for testing. Tried setting the driver to hd44780 and nothing seems to happen. Set ReportLevel to 5 on both lcdproc and LCDd.
On lcdproc the only output is
Jun 19 2024
Tentative first-shot code change here:
Jun 10 2024
I can probably help with this in August when I'll have access to one of these appliances again.
Jun 8 2024
Jul 12 2023
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
Jul 11 2023
@zoenan7 have you managed to report to upstream?
Aug 29 2022
Nov 6 2021
Nov 5 2021
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?
Nov 2 2021
@zoenan7 Sorry for the late reply! Yes, I got your email and could reproduce the crash using your PoC.
Oct 10 2021
Oct 8 2021
@dmbaturin Did you get my email? If not, please let me know and I will send it again
Sep 27 2021
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 daniil@vyos.io.
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.
Sep 26 2021
@zoenan7 Thanks for your research! You can send the PoC to daniil@vyos.io
Sep 19 2021
Sep 10 2021
Sep 3 2021
Aug 30 2021
Jul 19 2021
Jun 27 2021
Jun 16 2021
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
Jun 15 2021
Jun 14 2021
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)