Security Considerations - Common Ports - IoT/HA

Development
1

As the home assistant project grows, it becomes more and more important that the software solutions provided and the associated components are being hardened from attack. Especially considering the need for external access to the home-assistant software remotely for certain feature sets such as alexa smart home skills.

To Developers:
Are any steps being taken to ensure that 3rd party components (specifically 3rd party libraries providing functionality) are not collecting user data or allowing effectively a back door into the HA core.

To Users:
What steps do you take to ensure that your installation of HA is secure from attack? Firewall rules, running on non-common ports, filtering, etc.

What I desire from home assistant is that the issue of security isn’t just pushed into the realm of obfuscation (such as only running HA locally with no outside web access) because that mentality is not practical for the majority of cases that make home automation valuable.

2

There’s at least two threads discussing this on the forum, it’s worth a search. Though, using non-common ports is not security.

3

Well, this paragraph actually seems to be a new topic, which I at least not have seen in the other threads. And it’s actually a valid concern. I haven’t thought of it before, but I’m pretty sure that my library that’s being used for the HomeMatic component would be able to read all the files which the user the process is run by can read. Hence I could actually read all the configuration-files (including secrets, SSL certificates and keys etc.) and send them to some remote destination (if the firewall doesn’t block that).

Of course I don’t do that, and anybody looking at the library can see that. But the question would be: are the developers who accept PRs for new components looking into the corresponding libraries that are required for operation? Knowing how complex such libraries can be I actually doubt that, because that would be a ton of work. And even a once trusted library can become malicous and nobody would notice. In the HASS-code it’s only a “bump foo to 1.2.3”. If nobody checks that, a dependency-upgrade could be a real issue.

Since everything is clear to see for anybody I won’t expect malicious code being intruduced by the used dependencies. But it for sure can be done.

4

@danielperna84 thank you for the response. It is very likely that no one is reviewing 3rd party libraries and, very few, other than the contributors to that component, actually look at them.

I think one thing to note is that I am far less concerned with someone being malicious verses a contributor making mistakes in the development of his 3rd party library that opens up HA to new compromises and attacks. This is compounded by the community being extremely trust-worthy of home assistant and allowing it to interface with locks, home monitoring systems, etc.

To be clear, I do not advocate for foregoing the major benefits that HA can provide by preventing it from interface with as much of the outside world as possible. What I do advocate is that for a project such as HA, where security vulnerabilities can have a substantial impact on the user-base, that steps are procedures are taken by the owners/members/contributors of the project that encourage mindfulness of security.

However, this is clearly not happening as seen from the release notes for every version of home assistant so far. Doing a quick search on both the merged github requests and the home assistant release logs, I do not see any mention of a specific security fix for HA in the history of the project. Which implies to me that security is being ignored, like as it is for most software and it is abundantly clear that no software is without flaws.

@balloob - would you consider adding a static security testing tool to the HA build process as a first step?


These are just a few examples of ones that are opens source.

I’m not saying that this can be fixed overnight, or even that vulnerabilities exist (although probability suggests they do), but what I do wish for is an open dialog into these issues so ensure that home assistant is safe for use by everyone.

5

Ran bandit on the Home Assistant code, I will not pretend to understand how to interpret this:

https://hastebin.com/utarevujux.py

Regardless here are the final results:

Code scanned:
	Total lines of code: 122587
	Total lines skipped (#nosec): 0

Run metrics:
	Total issues (by severity):
		Undefined: 0.0
		Low: 99.0
		Medium: 21.0
		High: 27.0
	Total issues (by confidence):
		Undefined: 0.0
		Low: 0.0
		Medium: 6.0
		High: 141.0
Files skipped (0):
1 Like
6

Thanks @keatontaylor

I had a quick skim, and it looks like almost all the High severity issues are to be expected. There’s warnings about shell commands, for the shell components, FTP use for the FTP components, Telnet for those that interact with devices by telnet. I can only see one of the High severity issues that’s not a false positive - for XSS mitigation.

The Medium severity looks to be more 50/50 - many are for the use of MD5 vs SHA (when the use of MD5 is because the device/service requires it), others are for services listening on all interfaces. The rest look to be potential issues with not defanging XML and using yaml.load vs yaml.safe_load.

I glanced at the mass of Low severities, it’s a very mixed back - including it complaining about the use of the pseudo-random number generator - for random light effects.

Would you mind raising issues for the key ones - at least the XSS one line 403), and ideally the safe_load (line 413) and XML (line 354). That way it does get the attention of the developers :smiley:

1 Like