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).
Dear team,
Thanks for finding and solving this issue so quickly and working hard to keep us all safe!!
Regards.
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.
Would someone close this damn thread. It is overpopulated by fools (not directed at the poster I am replying to)
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.
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.
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?
No. The vulnerability is that someone from the outside could use a specially crafted URL to get your installation to give up sensitive info. So unless someone was trying, you won’t see anything in the logs.
Just like if you forget to lock your house door… unless someone tires the knob, your stuff won’t get stolen.
I read it the other way round as well:
It has come to our attention that certain custom integrations have security issues and could potentially leak sensitive information.
states clearly, that they have some custom integration in their mind and view.
And then I would appriviate, if they name them, so that the user can select, have a look in the code on their own, disable, create PRs on this customs, etc. etc. If there has been shuch case or not doesn’t matter, but to wich “certain integration” all this is related, should not be hidden.
If they name them before they’re fixed then it makes it easier for people with malicious intent to use that information.
You may not like what they’re doing, but they are doing the right thing by not “naming and shaming”.
Oh absolutely, holding back the details until the issue is fully mitigated is the right thing to do at this time. But this must only be a temporary measure until the situation is handled. After that, a full disclosure of the incident is absolutely required. There is no way around it. Anything other than full transparency can seriously damage the trust people will put into the platform.
To be fair, informing users about an incident that you know about is pretty much a basic requirement these days, even though not everybody does it. Depending on the specific type of incident or breach, not informing your users could actually have legal implications, even for open source projects.
@dvbit Perhaps you should get involved with the project if you have suggestions on how things should be done.
Is there any update as to which custom component(s) have security issues? And does 2021.1.3+ Disable the bad components, or just prevent them from causing harm?
Ok so Custom weather, mini media player, atomic calender, Spotify card, fold entity row card, ALL blocked.
EDIT: They all came back after I updated atomic calendar from HACS and reloaded the browser. PHEW!