With @nals74 permission, I’m sharing our analysis of his reports:
Route10 Report:
NVT: OpenWRT < 22.03.0 Information Disclosure Vulnerability (invalid)
This vulnerability is present in the version of cgi-io that typically ships with OpenWRT 21.02. However, this vulnerability does not apply to current Route10 firmware because 1) we do not use the stock version that ships with OpenWRT 21.02, and 2) we do not use cgi-io for any HTTP requests; all HTTP requests go through the lua handler (full source is at /lib/sh/lua if you want to analyze/confirm).
NVT: OpenWRT < 19.07.9, 21.x < 21.02.2 Multiple Vulnerabilities (XSS vulnerabilities) (invalid)
Route10 firmware does not use stock OpenWRT Luci Javascript in ANY capacity, and therefore is not vulnerable to any related XSS vulnerabilities. Also, you can confirm in the /lib/sh/lua script on the device that the HTTP referer is intentionally always verified before handling a response, thus mitigating any potential XSS attacks.
NVT: SSL/TLS: Certificate Expired (not applicable)
We’ve already discussed this on the forums in the past, but the stock OpenWRT certificate is not used for any operations under normal use; therefore this vulnerability does not apply. We will eventually phase out this certificate in favor of the Let’s Encrypt one, but it is not high priority as no SSL certificate is used for normal browser<>Route10 communication during setup. After initial configuration, the Let’s encrypt certificate is used for RADIUS and IPsec authentication. Initial setup is performed using unencrypted HTTP requests where the network administrator is expected to maintain security of their network for initial setup. Thereafter, standard TLS trust chains are used along with TLS 1.2+ encryption to secure communication with the controller, and the unencrypted HTTP configuration system is deactivated.
NVT: SSL/TLS: Renegotiation DoS Vulnerability (CVE under dispute)
This CVE is actually under dispute, but we are happy to apply any patch improvements to OpenSSL as they are released.
NVT: ICMP Timestamp Reply Information Disclosure (CVSS 2.1 - very low severity)
This is an extremely low severity issue which requires many other factors for successful exploitation. We are unaware of any time-based random number generator attacks in any cryptography libraries that we are using, so this does not apply. However, as a precaution, since we do not use timestamp information in ICMP packets, we have no issue disabling this functionality at low priority for our next firmware release.
NVT: TCP Timestamps Information Disclosure (CVSS 2.6 - very low severity)
This feature is required for modern TCP congestion control algorithms to perform most efficiently (lowering latency and increasing throughput), and the only downside is that a remote host may be able to tell the uptime of the system. This is an acceptable tradeoff, in our estimation.
—
Control Report:
NVT: TCP Timestamps Information Disclosure (CVSS 2.6 - very low severity)
This is the same as the last vulnerability above, and is a perfectly acceptable tradeoff for the enhanced performance it offers. The only downside is that a remote host may be able to tell the uptime of the system.
-Jeff