Security Bulletin

2 posts were split to a new topic: Xiaomi bluetooth Temperature/Humidity sensors

6 posts were split to a new topic: mDNS activity

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?

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