Well, my power is to tell everyone to ignore all future warnings which is probably not great. Updates happen on weekends, when I can find 4-6 hours to deal with whatever libraries and integrations are broken by the latest updates.
I had no idea these alternatives existed. Now I’m sad since I totally would’ve set up credstash, sounds great. Wonder why it’s being deprecated, must be a non obvious downside
1 Like
yeah, well, look at it from the bright side: your secrets file is still supported , this will be a deprecation without effort on your side 
My HA server is not exposed to the Internet. No port forwarding, etc. Am I generally safe?
Yes.The security vulnerability is/was via the internet.
AFAIK Docker user (I checked the Dockerfile on github repo) is root. I checked my container and runs indeed as root. This is a problem if there is an exploit that gets to the container. That’s only a matter of time this will happen.
Note that a container is not a trust-boundary… (despite some [incorrect] claims made).
Would be good to add a default ‘homeassistant’ user to the docker container, to force it to always run non-elevated
Defense in depth.
Comments?
it really doesn’t matter how many times it’s shown. It shouldn’t to normal user.
Limiting the target to administrators could be enough - still I don’t think using all possible channels incl mobile app is the proper approach. but yeah… for me writing warning that hot tea is hot is too much for me too. Maybe I’m different
I have no opinion on that. What I was talking about was that the warning was erroneously displayed once even after updating to the patched version.
That’s interesting. My security gateway picked up two attacks on my Home Assistant server from the TOR on 16th January. It has never picked up any attacks before.
Assuming the attack was successful, what do the attackers now have? My HA password?
Encrypting the passwords is a good idea, but that wouldn’t prevent this type of problem. If your encrypted vault gets stolen, like what could happen with this vulnerability, your password could eventually be decrypted using hashcat or something similar. Even though the encryption is not reversible (you can’t decrypt it, there isn’t a key to decrypt), brute force attacks would run every possible combination of passwords until it found a hash that matched. There’s also credential stuffing, which would allow immediate access without brute force attack.
This type of attack falls under the category of “data breach.” It’s the same as when a company informs you that your user data has been or may have been stolen and to update your passwords.
Guess we need to make an IPS/IDS/SIEM for HA. 
So who wants to implement spunk and snort with me?? Or better yet, let’s port Q-Radar community edition.
All joking aside, snort and splunk would be useful to allow integrating. Or zabbix instead of splunk. The only requirement really would be packaging the remote agent into the core or os. It can be installed on core docker supervised, but it would get wiped on each reboot. Rsyslog would be nice even.
Has the idea of rebasing the www folder been considered? Or chrooting/jailing it? Even with directory traversal, if www were the top level, and the community directory also top level, traversal would be stopped unless they managed to escape the jail, which wouldn’t be happening without shell access.
Just some ideas…
1 Like
I got snort up and running on pfsense now. Now I just need to figure out if I actually was able to configure it correctly. It does alert on a large chunk of traffic coming out of home assistant, but googling leads me to believe it’s harmless.
Well, throwing in my 2 cents as I was wondering from the beginning and still don´t feel comfortable with it:
secrets.yaml containing plaintext authentication data like usernames, passwords, tokens, api keys, …
Isn´t there a better option? Like hashing them e. g. Anything on the security roadmap?
1 Like
Really would like to know this as well. Hopefully the solution also covers config entries so integrations created via UI don’t store their credentials plaintext in .storage. I understand that the security can’t be absolute here because if HA doesn’t have access to the key to decrypt credentials then user input would be required to restart it which I imagine is a bad trade-off for most users.
But I still think there has to be a way to improve secret management. Seems like there should be some way to make it so HA can provide decrypted secret values to integrations upon request at runtime but anyone looking at the the underlying filesystem that HA sees would see only encrypted values.
Either that or maybe un-deprecate the secret credstash approach Marius pointed out that I never knew existed. That wouldn’t cover UI configured integrations though sadly.
2 Likes
I have installed the latest update, after the update my hyperion leds play crazy. The leds turn on, off, on, off and so on. My brother and i have the same problem.
This is completely unrelated to the topic “security disclosure”.
Please start your own topic if you are having trouble with an integration.
It’s responses like this which make me trust a company or project more.
I am thinking to make a custom component that will generate blueprints with a (graphical/blockly-like editor). Want to check if there is any reference/guideline on what kind of python access to the system is allowed? Such as if I can add/remove files & folders in the blueprints folder? And modifying the automation.yaml?
My current understanding is modifying HA source code and configuration.yaml would be malicious, but where is the boundary line?
frigate integration vulnerable.
while not logged in, anyone can brute force the following urls:
https://HAinstance.com/api/frigate/notifications/{{eventIDbruteForce}}/{CommonCameraNames}/clip.mp4https://HAinstance.com/api/frigate/notifications/{{eventIDbruteForce}}/thumbnail.jpg