Security Bulletin

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”.

7 Likes

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.

4 Likes

3 posts were split to a new topic: Using HA as an alarm system

@dvbit Perhaps you should get involved with the project if you have suggestions on how things should be done.

2 Likes

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!

The source is reviewable… Certain http calls are filtered, not specific integrations, as referenced previously in this thread.

2 Likes

Hmmmm. Got this about an hr ago. I live in sydney. Never before seen a geo thats not roughly where i am. Slightly worrying given this announcement. And my correct username. And a successful login. Ive since upgraded my docker image (now on v2021.1.4, previously v0.115.6). Perhaps too late? Ive just cycled my hass password, just in case.

Anyone else noticed this? (This is the ‘authenticated’ addon BTW, if you dont have it and want it).

Do you use any cloud service? I get hits from Google Assistant for instance. Have you done a Whois on the connecting IP address?

Good shout david. Seems i jumped at a ghost. I did on the weekend integrate google assistant (which hits an inbound API in my hass). So it seems to be that. Apologies if i spooked anyone. Confirmation bias!! (And im a network dude, i really should have checked the IP as step one).

1 Like

Yeah I use authenticated myself. I actually added the google ranges to an ignore or allowed list so I don’t get continual persistent notifications…

1 Like

BTW is that a free tool you used there? Do you have a link - I would like to check it out…

Yup >> https://mxtoolbox.com/SuperTool.aspx

2 Likes

I tried to update HA to version 2021.1.4. I got a failure message and the following log:
21-01-19 12:54:07 ERROR (SyncWorker_1) [supervisor.docker.interface] Can’t install homeassistant/raspberrypi3-homeassistant:2021.1.4 -> 500 Server Error for http+docker://localhost/v1.40/images/create?tag=2021.1.4&fromImage=homeassistant%2Fraspberrypi3-homeassistant: Internal Server Error (“Get “https://registry-1.docker.io/v2/homeassistant/raspberrypi3-homeassistant/manifests/2021.1.4”: Get “https://auth.docker.io/token?scope=repository%3Ahomeassistant%2Fraspberrypi3-homeassistant%3Apull&service=registry.docker.io”: context deadline exceeded (Client.Timeout exceeded while awaiting headers)”).
What does this mean?

That can be caused by an outdated version of HassOS, please make sure you are running HassOS 5.10 as well.

You are right. My current version is 5.9. But if I try the update to 5.10 I got also a failsure message with the log:
ERROR (MainThread) [supervisor.hassos] Home Assistant Operating System update failed with: signature verification failed: error:2E09A09E:CMS routines:CMS_SignerInfo_verify_content:verification failure

You can update HA OS manually using a USB key. See doc here: https://github.com/home-assistant/operating-system/blob/038f1b4bd69c952769fd020db0eae0f511570d19/Documentation/configuration.md

1 Like