Interesting read about some vulnerabilities that got patched earlier this month. What worries me a bit is that in the blog post the actual patch notes are linked, but I don’t see any mention of security fixes there…
v2 recently had a firmware update, but what about v1 or Connect Home users? V1 hasn’t received an update in forever and Connect Home is behind a couple versions. Maybe @posborne can provide some details?
There’s a ton of highly technical detail in the article and vulnerability descriptions, but based on skimming it, I think:
-
most of the vulnerabilities do not apply to Hub V1 because V1 does not support local execution nor video processing.
-
some of the vulnerabilities are not even “in” the Hub - they are a result of functionality provided by the cloud to hub communication, so a cloud fix would also remedy the issue for all model Hubs.
-
some of the remaining vulnerabilities may not be fixable in Hub V1 due to its substantially different firmware. While it may be possible, it might be considered reasonable by SmartThings to not put in the special effort, since the risks are small as well as the number of people affected.
but what about you?!
As noted in the blog post, we have been working with TALOS over the course of the disclosure period for these issues to ensure that they are well understood and patched. TALOS performed testing of exploits aginst the V2 hub (which we have patched) but, of course, we have also taken into consideration how these vulnerabilities might impact other targets that Work as a SmartThings Hub (e.g. Connect Home, Nvidia Shield, etc.).
The vast majority of the vulnerabilities disclosed were attacks against the VideoCore process on the V2 hub by way of requests local network requests via, e.g., HubAction HTTP requests or other vectors that require user permissions (not attacks via just being on the same LAN). No other hub contains this functionality and, as such, are not affected by these vulnerabilities. These vulnerabilities were patched in previous releases of the hub firmware (prior to today’s release) and changes were deployed in the cloud to prevent SmartApps and DTHs outside of the SmartThings published video-core DTH/SA from making calls to localhost/127.0.0.1.
The only vulnerability directly affecting hubCore was TALOS-2018-0594 || Cisco Talos Intelligence Group - Comprehensive Threat Intelligence and this functionality is only enabled (compiled in) on the V2 hub. This, like the other issues, has been patched in the releases prior to today’s release.
6 Likes
Could these patches have affect httpsget commands using ec encripton from other api’s e.g. cloudfair?
Thanks for the clarification Paul. Regarding your comment on the hubAction HTTP calls - what impact would have in existing functionality, does it just impact “localhost” calls or any other interaction with local or internet devices/addresses?
Is there a difference in privilege / functionality between ST “published” Apps/DTH and user self published apps/DTH?
No, the cloud changes have been deployed for some time now and would only impact calls to localhost (which nothing except video should have a reason to be doing).
It should have no other impact.
In some specific cases there are, especially as it relates to features that we may not be safe to expose broadly or for APIs which are not planned to be public. In general, however, the SAs/DTHs we publish are no different than what you would be able to self-publish. In fact, this is often how those changes are tested during the development cycle (in addition to full development and staging environments).
5 Likes