34 posts were split to a new topic: Not about the Security bulleting
Any estimate to when more details will be available, so that I don’t have to keep checking the blog post? 
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?
I’m pretty sure they’ll accept PRs improving on that, without restricting functionality.
1 Like
Note that you need card-mod for that. Also, instead of using rest sensors, you might be able to use the updater or version integrations.
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.
16 Likes
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.
1 Like
A cynic may suggest that tinging this update with a security colouring encourages updating
1 Like
If you are doubting the name of your installation method you are using:
Home Assistant Menubar -> Configuration -> Information
It will be the second item in the list: Installation Type
Please note! No matter which installation type you are running. All of them include (or is) the Home Assistant Core. Which is the thing one should upgrade as announced in this security bulletin. So this security bulletin applies to EVERY installation of Home Assistant (not matter the type).
2 Likes
Dear team,
Thanks for finding and solving this issue so quickly and working hard to keep us all safe!!
Regards.
2 Likes
Hi guys, thank you for this information. I have updated. However I’m a little bit concerned about users who do not read every day the community. In fact I always have been missing a feature that updates are displayed automatically in the notifications.
Yes, I have written an automation to do so, but I am pretty sure the most people are not doing this. This topics shows even more how important it is.
Off topic, If you are going to think about it, showing all kind of updates would be appreciated (hacs, hassos, supervisor, core)
Nothing about his post insinuated even remotely what you started waffling on about. Wind yourself in. I think everyone is equally eager to understand what the issue is.
1 Like
Would someone close this damn thread. It is overpopulated by fools (not directed at the poster I am replying to)
7 Likes
These sensors have an unavailable state until you set a timer.
That’s how it works since 2021.1.2
Hi Iceman,
With all due respect, I think you are completely misunderstanding what custom components do. They are loaded along with regular components and are given full access. If you are concerned about security, you should not run unknown code on your server.
This security alert does not apply to HA core, or any of the HA addons, which communicate with HA through api requests. It applies to custom components loaded directly into home assistant. If you are uncomfortable with the auditing process for any custom code running on your server, you should not run it.
3 Likes
Reading the source code of the commit, it seems they are blocking some certain very specific things such as directory traversal. It should be possible to identify those which were just poorly designed without obfuscation.
I would like to think this was a feature to some naive developers who’s legitimate plugin will no longer work. However for those whom have put in effort to obfuscate or not directly reference paths, it would be more difficult.
I, for one, am glad Paulus, Franck and Co. have discovered the problem and are working on it. I’m glad they’ve informed us there is a problem and also glad they’ve given no specifics as to what that problem is other than it has something to do with the installation of (a) custom component(s).
I believe, until they’ve suitably blocked the risk from (re)occurring, it’s best we not know what that problem is; else, some slimebag cracker is going to promptly see if s/he can exploit it before it’s blocked/fixed.
Again, thankyou to the HA Team.
4 Likes
The PRs added warning log statements for the situations where malicious behavior is detected.
So if there are no warnings in the core logs all installed custom components are “clean”, right?