you may need to update again, this is a new vulnerability
Well done - a very clear, transparent and inclusive security response - thank you.
First, thank you for the prompt response,
I’ve already removed/changed everything in my config/secrets files, but this episode has made me realize that I have no idea how to effectively secure other integrations that connect to HA via api using the UI after a breach. For example, for my ecobee integration, do I need to delete it and start completely from scratch to obtain a new api key from ecobee? Is there a simpler way to do that from within HA? If so, would that be sufficient or do I need to also change my password on ecobee.com?
I know the standard better-safe-than-sorry advice is “reset everything,” but I would appreciate some advice on how to deal with these kinds of integrations.
Maybe I’m missing a trick? (it is late here…)
When I pull the latest version for docker, I seem to be getting 2021.1.4 not 2021.1.5…
Just cleaned out my google developer api credentials and started over. Something I haven’t seen mentioned anywhere else: I had a few ssh command line sensors pulling temperatures off of my two main proxmox hosts (one of which runs my pfsense vm)…and those keys were in /config/.ssh! ugghhhhh
No more ssh sensors for me. I’m pulling my google calendar integration too. It’s just too risky.
Anyone that has updated to 2021.1.5 has these problems?
Nope. What does config checker say? Maybe Remove automations and add back one-by-one (reload automations between each addition and check log after each reload). Did you make any changes since last restart before updating?
1 Like
I have just found this on my log:
2021-01-24 08:31:37 ERROR (MainThread) [homeassistant.setup] Setup of automation is taking longer than 300 seconds. Startup will proceed without waiting any longer
Yes, I am trying to use a backup automations file, but of course I cannot reload automations from server config and neither restart HA. I am gonna try a hard reset powering off the current.
Can you restart from command line?
Hard reset should be avoided where you can
1 Like
Why not? Should be able to.
1 Like
Overall a quick response to threats is always welcome 
I would’ve appreciated the hint that the vulnerability is mainly affecting installations exposed to the internet. The “internal threat” scenario of a bad actor within the network is probably not relevant for most users.
I wonder, however, whether sensitive data could just leaked by custom components / addons to the internet without breaching the network - much like with “hijacked” chrome extensions that turned bad after they switched ownership. Are there any restrictions or checks for trackers or otherwise outbound traffic? Is the scope of the data visible to a custom component limited at all?
Good advise @samnewman86, but too late. When you have your house stopped, you don’t think clever…
I don’t know @DavidFW1960, I just couldn’t. I tried from server config and from supervisor, but with no luck. Perhaps the automations component is a mandatory one, or something like that.
However, after replace with a previous automations.yaml file and hard reset, it has come to live again. But here is a funny thing, I have restored again my present file (the one that didn’t load after update HA) and after resetting HA, everything works as before. 
Maybe my HA wanted to spend some time with me this Sunday morning…
Thank you for your assistance.
I often find I need to restart a couple of times after an update… I think some custom components need some time to load some dependencies causing problems. These days HA will pretty much start even if there are config issues so you can normally at least troubleshoot
1 Like
Code that is already running within your HA instance is capable of starting an outbound conversation with whatever server it wants (Assumes your HA instance can freely talk to the internet). Any routes you may have setup inbound are of course always potentially susceptible, but code that’s already running internally (HACS etc.) can ‘sniff’ your secrets.yaml file, or any other HA file and communicate that out to wherever it wants. I posted about this back in early December on the FB group. Seems odd that it’s now getting a lot of attention…
1 Like
Thanks a lot guys for your quick response on this matter!
Update went smooth.
I know everyone would not be on board with this. But perhaps adding an option for automatic updates of point releases when a security patch comes out to the supervisor.
For instance
If you are currently running core 2021.1.X
then it could automatically update you to 2021.1.5
If you are still on core 0.118.3 or 2020.12.1
then it would not auto update as most of the breaking changes are in that point release and not the maintenance releases.
With security fixes I often prefer that whatever system I’m using pick them up immediately, with features updates I’m good at checking for the update and applying it myself, specifically with Home Assistant so that I can ensure that nothing will break.
1 Like
I got this message in the supervisor when pushing the update button:
21-01-24 11:41:41 INFO (SyncWorker_0) [supervisor.docker.interface] Downloading docker image homeassistant/raspberrypi3-homeassistant with tag 2021.1.5.
21-01-24 11:41:41 ERROR (SyncWorker_0) [supervisor.docker.interface] Can't install homeassistant/raspberrypi3-homeassistant:2021.1.5 -> 500 Server Error for http+docker://localhost/v1.40/images/create?tag=2021.1.5&fromImage=homeassistant%2Fraspberrypi3-homeassistant: Internal Server Error ("Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on [::1]:53: read udp [::1]:43916->[::1]:53: read: connection refused").
21-01-24 11:41:41 WARNING (MainThread) [supervisor.homeassistant.core] Updating Home Assistant image failed
What could be wrong?
PS: Ok, tried it a second time and it started to update.
Isn’t it an option to redesign the current custome_components and move to containers for custom integration instead the same file system as core?
So every component have its own user in home assistant with a long lived token and the containers only allowed to communicate trough the API. Also a benefit for the logging you can see who (integration) is triggering devices. For local folder mapping a filter in place and opt-in so you must give the container access to local folder / files
1 Like
Update from 2021.1.4 to 5 failed.
Restart not possible, connect to cloud not possible.
I have this strange message in my logs:
Logger: homeassistant.components.hassio.http
Source: components/hassio/http.py:126
Integration: Hass.io (documentation, issues)
First occurred: 13:07:03 (5 occurrences)
Last logged: 13:07:06
Client error on api snapshots/reload request Cannot connect to host 172.30.32.2:80 ssl:default [Connect call failed ('172.30.32.2', 80)]
Client error on api supervisor/logs request Cannot connect to host 172.30.32.2:80 ssl:default [Connect call failed ('172.30.32.2', 80)]
Client error on api network/info request Cannot connect to host 172.30.32.2:80 ssl:default [Connect call failed ('172.30.32.2', 80)]
Client error on api supervisor/stats request Cannot connect to host 172.30.32.2:80 ssl:default [Connect call failed ('172.30.32.2', 80)]
Client error on api core/stats request Cannot connect to host 172.30.32.2:80 ssl:default [Connect call failed ('172.30.32.2', 80)]
No connect to cloud was possible.
All sensors to the OS (CPU,SWAP etx) were unavailable.
Places Component was unavailable
Browser_mod could not be installed
A restart wasn’t possible. Click on restart was simply ignored.
Now, after the rollback to 2021.1.4, everything’s working again.
What con I do now? What went wrong?
Hi, I’m running HA core in docker container. I’ve pulled the latest image, run docker-compose up --force-recreate, but still see 2021.1.3 under Configuration / Info. What am I missing?