Security Disclosure 2: vulnerabilities in custom integrations HACS, Font Awesome and others

[pove]

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.

[DavidFW1960 (David)]

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

[dougle03 (Peter Kay)]

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…

[Nick4 (Nick)]

Thanks a lot guys for your quick response on this matter!
Update went smooth.

[jpreiditsch (Joe Preiditsch)]

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.

[Pirol62 (Jörg Nauen)]

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.

[bsmeding (Bart Smeding)]

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

[Pirol62 (Jörg Nauen)]

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?

[BalassaMarton (Márton Balassa)]

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?

[pedromargarido]

After changing all passwords I’m getting a “login attempt failed” notification every minute.

As I use nginx add-on, HA just shows the nginx container ip address, so I can’t know which device/service is is trying to connect to my HA and failing. I couldn’t find how to access the nginx full logs.

The Alexa integration is working fine, both my android apps are working fine. I don’t know how to debug where this connection is coming from.

Does someone has an idea how to proceed to solve this problem?

[Burningstone]

@pedromargarido

As I use nginx add-on, HA just shows the nginx container ip address,

That’s a configuration issue, my NGINX shows the ip address of the device that tries to login.

As far as I remwmber, this is the setting for NGINX that you need to set under location:

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

And this in home assistant:

http:
  use_x_forwarded_for: true
  trusted_proxies: 
    - 172.19.0.7

Where trusted_proxies is the IP of the NGINX container.

[pedromargarido]

Cool, that’s good to know!

Just a question. As I’m using NGINX as a HASSIO add-on where/how should I include this line?

My configuration is like this:

Edit.

Thank you very much, it solved the problem.

I just created a nginx_proxy_default.conf file in the /share directory and inserted the configuration you told me, now I can see the failed connection is comming from AWS.

[Norbsen]

I would like to thank the HA team and Nabu Casa for the swift response! This is a free open-source project and we all appreciate your time and effort. Maybe, security was not the main focus so far in the development and these incidents may get them to a higher priority.

I was always wondering why we have to store passwords and credentials in plain text in a file somewhere in the network. I think these issues show that HA needs an integrated encrypted password and credential storage where all the passwords can be safely stored and integrations and addons can access them via an API call with rights that need to be granted by the user.

Is something like this coming or planned in the near future? I mean the security breach could be non-HA related but these passwords still hang around in the network.

[Gusman]

Hi,
Thanks team for all this security updates.
This vulnerability show that internal Encrypted Vault to share different password of addons custom integration or other is now mandatory. Plan text password in yaml files is now not possible for a wonderfull product like HomeAssitant

[tom_l]

See frenk’s answer to this:

Managing secrets

I’m interested in that too… the problem is, it doesn’t work as you stated Either HA needs to be able to decrypt by itself (which defeats the encryption), or it cannot auto-start and every time it starts you’ll need to enter the decryption key. As a matter of fact, we have those methods available but are now deprecated and pending removal, as while it sounds ideal, it is fairly unusable. So, if you have can design a way that works like you say, please, contribute it. I’m interest…

[Norbsen]

I read the answer, but it is not fully convincing. Why is it too hard to ask for a password (optionally if the user has configured it in HA) during startup time to get the vault access? This is similar to OS passwords, UEFI passwords, etc. Once logged it, sure HA is then able to read all passwords in the vault, but it should come with a rights management such that the admin can decide which (custom-)integration has access to which pw.
Moreover, the larger fear is that anywhere in the network could be a security breach and access your secrets.yaml file vs. only HA must be breached with a vault. Just this difference is already huge. Of course, this could always be made optional if there is no need for these security measures.

[vacari]

Version
supervisor-2021.01.5

Newest Version
supervisor-2021.01.7

What is this? New Security Path?

[tom_l]

It updates when the security alert is shown. Used to be for core versions less than 2021.1.3, is now for versions less than 2021.1.5.

[ha_steve]

@Norbsen

I read the answer, but it is not fully convincing. Why is it too hard to ask for a password (optionally if the user has configured it in HA) during startup time to get the vault access? This is similar to OS passwords, UEFI passwords, etc. Once logged it, sure HA is then able to read all passwords in the vault, but it should come with a rights management such that the admin can decide which (custom-)integration has access to which pw.

Because, any reboot/restart due to power failure, software glitch, etc would keep HA from starting, which could be an issue if you aren’t home when this happens

[Norbsen]

Totally understand that. My point is just that everyone should (be able) to decide on his/her own whether the inconvience of a non-booting HA when not at home is worse than a compromised Google/Amazon/Whatever account or vice versa.