So… the HA team shouldn’t have released their “fix” (nothing in HA was technically broken) to protect against the possible “exploit” and instead, waited for the third party applications, that may have been unscrupulously extracting data about your home on purpose, to remove that behavior from their code?
No. you misunderstood me or I havent written it down in a proper way (English is not my native tongue).
Let me try again. I dont want my message to be misinterpreted.
First of all: I appreciate it a lot (hence the thank you) that the devs of Home Assistant fixed the issue on the home assistant side and that they did inform us that there is a possible issue outside home assistant. I did not say or intended to say that they shouldn’t have. On the contrary I thank them.
What I meanth is that I would understand that currently they don’t fully explain what custom integration could be causing a possible risk. That’s what I meant with the ‘strategy’. I assumed that if there is an external developer in good faith who wants to fix the issue in custom integration. And that they need some time to fix it. With the immediate treath being stopped there is some time to wait with providing information untill the external software had the opportunity to fix it. And make sure the root cause also is fixed.
Like it is done in cases of data breaches that where possible; explain what happened after it’s fixed to prevent others using the exploit.
I’d love to hear it, because as a newer user I can learn what makes my system vulnerable.
Okay, I understand not everyone can understand these things but sometimes it’s best to assume we are in good hands and be patient: The fix (filter) is in release .3 that everyone was advised to upgrade to. Regardless of how many, if any, active inappropriateness was out there, HA will now block and log the activity, and we all are reminded that custom code, carries a risk that the HA team cannot be liable for.
Wow. Since you reply to my message I feel you see me as a person without trust and patience. I just hope my explanation above helped to make my point. Because the way you describe me as not understanding shows there is incorrect. I have patience and trust. I dont have any demands (only things i would love to see) and am very gratefull to be able to use open source software other wrote in their spare time.
For everyone that works on HA, thank you for all that you do.
Because there was none. This is pro-active mitigation.
I realise English is not your first language but read the announcement again. There is no suggestion that anything bad has happened, just that they (the devs) recognise the possibility it could happen and are reacting to that.
Think of it this way:
Your chicken coup has holes. We want to patch them before the varmints get in. They ain’t got in yet but we see where they could.
I disagree.
There is no way the Hass Team could know if the security hole has been used until now.
So it is not correct to say it has not happened in the exact same way as it is not correct to say it is happened.
I understand that the Hass developers cannot ans should not vet and check custom components.
However what should be done is a better management fo custom components.
By better I mean : some restrictions on capabilities / accesses available to custom components.
I am thinking about a special user to run custom components which is more controlled / walled
I am not knowledgeable enough to understand if this is feasible but something shall be done.
I suggest that maybe next what the heck may be dedicated to security and privacy…
Tinkerer
(aka DubhAd on GitHub)
Split this topic
111
If you want to discuss UI or update thingies, please create a separate topic. Let’s keep things nice and on topic so everybody can benefit from the actual issue presented in this thread.
There are a number of custom components offering integrations with banks, energy providers, crypto currency wallets, etc.
If a malicious actor wanted to, those integrations could be exploited to intentionally request (the user to enter), then exfiltrate those credentials allowing financial fraud (among other abuse).
Put aside whether you think it’s a good idea to link those services into a home automation platform, let alone use a custom component to do it (because if you think that’s a bad bad idea, I agree, but we’re not “everyone”).
So no, there are plenty of other potential attacks possible other than just turning your house into a haunted mansion.
(I’m not insinuating that any known component (custom or otherwise) does this, or that that this remediation covers that potential abuse. I’m just highlighting that the risk is potentially worse than just uncooperative home lighting)
I mean I agree it probably is, but has this been officially confirmed anywhere or is this just hypothetical ?
Communicating security breaches is tricky, especially in open source. So I think we should indeed cut the devs some slack here and see how this unfolds. But transparency in communication is key. Commercial actors always get slammed (and rightfully so) for being opaque around security incidents. And lack of transparency will inevitably open the door to conspiracy theories, as clearly demonstrated by the current worldwide situation. That said, I’m sure that the devs will give us an updated situation when they sorted out things internally.
maybe I missed it in the heated discussion above , but, now we are all on the necessary version, is the idea of this restricted custom components access, part of the future core HA design?
If you want to understand the specific attack that is the focus of this security bulletin, you only need to look at the “filter” patch to HA Core (linked above). This is not about a component intentionally sending data to an outside entity. This is about a component that might, unintentionally, fail to properly sanitize API requests coming in to HA Core allowing someone to access information which was not the intent of the component. Input sanitization is complex because it has many dimensions and some are not obvious to casual developers. This is open source so the only guarantee you have is if you, yourself study the code and make or suggest improvements to the API security model through PRs. You are deluding yourself if you think you can demand anything of open source developers. Suggest, yes; beg, yes; demand, well YMMV.
For all those that thought this was about components sending out data; I am amused at how many of you don’t seem to grasp that literally every single component in HA that communicates with an outside service is leaking information. If you don’t like that and want to prevent the leak then you need to put every IOT device, including HA, on a separate WiFi with no Internet access.
I’ll illustrate my point with a simple example that probably applies to every person on this thread. When you installed HA did you give it accurate location information? e.g. did you give it the actual GPS coordinates of your house? Well then the default weather component (met.no) or any other weather component you’ve enabled is “leaking” your exact location and the fact that you are running HA. Even if the first thing you did after you started HA for the first time was to disable met.no; there is a good chance that it sent your location to met.no at least one time.
Another example that has nothing to do with HA: If you have a recent roomba model with mapping and you let it on your WiFi with Internet access; then the roobma is leaking a floor plan of your house and could be leaking the contents of your house too. It has object detection and could report all the objects it recognizes; even people.
Disconnecting these things from the Internet or otherwise blocking the information “leak” greatly diminishes their value. So before you get out the pitchforks demanding changes, you need to think about the ramifications of what you are asking.
Last a bit of advice. You should not give HA access to any data that you consider sensitive. Anyone giving HA credentials to their financial institution is just, IMO, crazy. This really applies to every IOT device on the market; none of them are secure enough.
This is an interesting case study in how decisions made months, even years prior can have lasting effects down the road. When I started using Home Assistant, I opted for the ‘Venv on a VM’ route because, for me, it was far more powerful and reliable than Hassio on a Raspberry Pi with an SD Card. Here we are, years later, and Supervised HA now meets my standards for use while the venv languishes behind, mainly because upgrading is very, very manual. (I’ve lost track of how many times I’ve broken my venv because python wasn’t upgraded correctly.)
But I digress… I still expect the devs to tell us which custom components they’ve identified as suspect so that we may take appropriate action. Updating HA isn’t the only way to address this problem, especially if the problem exists because of a custom component written by an unscrupulous programmer.
