Where are the vulnerabilities being tracked for the Alta devices?
I have a Router10 and the controller. I ran a vulnerability scan on both and came across some high-severity CVEs discovered.
Please report any findings to security@alta.inc . Thank you!
This is a fair question, where are the vulnerabilities being tracked?
I have searched all release notes and do not find any references to fixed CVEs or even the mention of a single security remediation. Where is this communicated? Best practice would be to inform the community of any security related updates after release to ensure prompt installation of the update.
Having dealt with the issues on updating the self hosted controller via Docker, I know that the underlying OS is not being patched or updated by Alta Labs which opens up some concerns and now it is at a point where no more OS updates can be applied due to the postgres upgrade issue.
I think it is critical that Alta Labs communicate the security vulnerabilities they remediate with each firmware update, this is of course assuming you are actually remediating OpenWrt vulnerabilities as they are identified.
1 Like
Per your recommendation. I sent a copy of the reports to the email address.
1 Like
@ecs-solutions We’ve already explained multiple times that we are unable to reproduce the postgres version upgrade issue that you are having. We cannot fix something that we cannot reproduce, but once we can, we are happy to fix it. If you can provide better step-by-step instructions, perhaps we can take another look. Once the system has time to automatically update (or manual update is performed), it will have all security updates applied.
In all of our internal controllers, the underlying operating system upgrades successfully using the ubuntu-jammy security repo (i.e. only security updates are applied), which will continue to receive updates until April 2027. By default, only security updates are applied automatically, but we cannot reproduce any upgrade issues even if we apply all non-security updates, as well.
I have sent you an analysis of your report. No high severity issues have been confirmed on our end, and I will share the full analysis here if you desire. There is a very low severity ICMP timestamp issue (CVSS 2.1, ICMP timestamp requests are responded to) that we will resolve at low priority in the next release of Route10.
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
6 Likes
I know you cannot replicate or fix the docker issue. This is no longer an issue for us as we’ve completed the upgrade to that site. The issue we have right now is that we have taken on 2 more clients that were unhappy with their previous provider and both sites are full Alta Labs stacks. We have them stabilized for now. Both these clients work with the legislature and are adamant that no changes be made until the session is over as they need stable connectivity 24/7 so we cannot replace their equipment for several more weeks. We’ve blocked the local controller from Internet access so it will not update and have disabled auto updates on all devices.
My concern is, if there is a security related update, we would want to know and be able to determine if we should force the update. I’ve looked through all the release notes to-date and have not seen any references to security fixes, CVEs, etc. As I mentioned before, I assume you do patch security issues from the underlying OpenWRT base if necessary, my question is where do you document security updates for firmware releases?
2 Likes
@ecs-solutions There have not been any critical CVEs assigned to any Alta Labs equipment specifically up to this point. Of course, we use plenty of open-source software that does have potential CVEs assigned, but the applicability of those CVEs depends entirely on the way the library/tool is used (as you can see in the above report).
There are no currently applicable CVEs with high or even medium severity for our equipment/software, that we are aware of. If we were to discover a high-severity CVE that applies to our equipment/software, we would enforce an embargo period, working closely with the discloser to release details at an agreed upon date/time, so that they can get credit for finding the vulnerability, and we can make sure we have all of our ducks in a row for public release/disclosure. Hopefully this helps.
5 Likes
Thank you, this is exactly what I was needing.
1 Like