A friend recently raised a valid concern.
What is to stop a bad actor embedding malicious code in a community driver/app?
What safeguards or processes should/are the HE Company / users following to protect against this?
Do you use Windows and have you ever installed an compiled EXE?
The community apps/drivers are open source - so everyone can view and check the code inside; In contrast to all the closed source programms on Windows...
Same is of course valid for other operating systems, e.g. smartphones.
7 Likes
If you’re unable to review the code yourself (e.g. you don’t know anything about computer programming, like me), then you should stick with drivers and apps that are well-regarded here in the community.
Edit: or use only the built-in apps and drivers. Bottom line is, don’t install just anything from anyone unless you know what you’re doing.
14 Likes
The libraries that can be used by Groovy apps/drivers are restricted to a whitelisted list. Which does provide limits on the damage that can be caused by a malicious actor.
And what @marktheknife said ....
13 Likes
@Jost Actually I don't use Windows but I get your point.
In Windows it is expected that Windows Defender is turned on and most people use anti Virus software.
What anti malware policies, processes or procedures are in place for HE if any.
This is not a dig at HE it is discussion to identify if a risk is of concern and what mitigation steps can be taken.
If there is no malware detection/blocking - ie a process in HE that identifies when a Driver /App is invoking an embedded url - does it force a confirmation from the HE device Admin?
I understand it if the threat of malware in HE is not considered a risk and not worth expending any time on it.
It just means that I will have to look at ways of treating HE as a potential hostile actor, like I do for most of the iot devices on my LAN, not an issue, just goes on a VLAN and place a monitor on it to spot aberrant behaviour.
Not an issue at all, but as my friend pointed out, there are probably alot of people who use HE who would not spot a hex url or a variable concatenation of a url in the text format of the Driver/App.
He raises a valid point worthy of discussion to determine level and response to threat.
2 Likes
I am the friend that raised the concern 
Interested to understand more about this whitelisting, will RTFM is available.
Also agree that the code is open for all to read which is only ever a good thing, but has a requirement of some level of programming knowledge, which I would guess a large number of user do not have.
Not sure the windows executable argument here, as mentioned security tools on Windows also application signing is involved for some level of trust, but of course if you download an exe from a forum of untrusted source you are taking a big risk but anti-malware will de-risk somewhat, I am talking basic malware variants here too.
Guess the bottom line is understanding the code/drivers apps you are deploying into HE, new to HE and was sounding something out with a security hat on, liking HE so far apart from some newbie mistakes down to learning curve and close to converting over.
Just wanted to discuss the fact that I have 5 drivers so far in 2 days that I have pulled from this forum and although I have some basic programming knowledge, am seeing the potential for anyone to upload a driver and some obfuscated code (hex or base64 (not sure if it will decode base64 just an example)) which will run something undesired.
This conversation I'm sure will help settle any concerns for other visiting too.
3 Likes
Welcome @Frenchish!!!!
You will find the community here is excellent !
A security concern expressed is to be encouraged as it allows everyone to become more security aware and helps build a security frame of mind.
Hopeful that HE build in some baseline approvals for any driver/app that requires IP access, even if it only identifies which drivers/apps are using IP in a report to the user.
It would be a big leap forward in posture.
1 Like
Ultimately, if you don’t understand the code you choose to install on your system, then you’re reliant on the good will of the community devs, or other users here that also make use of community code and can understand/attest to its benign nature.
I’ll leave it to people smarter than me to clarify what’s technically possible vs. impossible for an unscrupulous developer to accomplish on your system if they were inclined to behave badly.
But you are your best insurance policy, Hubitat the company can’t be expected to do that for all users.
2 Likes
The same analogy applies to MacOS and Linux.
2 Likes
That's part of the reason that HE requires the user to select specific devices to grant application access to instead of giving them free rein. The number of interfaces directly able to talk with the hub are also limited to protect it from harm. This is also the reason that not all software libraries are whitelisted, and why the firmware upgrades only have one path.
Overall, I feel that the HE developers and staff have made some very solid decisions as regards protecting the platform.
5 Likes
Didn't disagree
.....
The purpose of the question was to
a. Identify potential exploit opportunities
b. Quantify risk
c. Identify mitigations
This is a discovery, no criticism intended or implied.
This will enable informed decisions to played out.
3 Likes
But it sure would be nice to see more adoption & integration of community dev products once proof of concept has validated the merit & usefulness of some of the things you guys develop.
Permissions & credits due of course.... I assume a bunch of you would love to stop having to maintain some of these through multiple version upgrades and put your creative brains onto new & novel problems instead.
Good to know the built defences for HE.
My questions was more about HE being used as a launch platform for exploit.
I can reduce that risk by putting the HE on an iot vlan and place a monitor on it for odd behaviours so not a concern for me and an option for all other HE users.
So not an issue
I'd argue that if it's enough of a concern that you would go to those measures... then it is an issue for the 90% of the rest of the buyers of HE hubs that wouldn't (or rather, wouldn't know how)
I think some of the ideas behind community apps do find their way into future enhancements over time, but I'd rather the HE staff devote themselves to platform enhancements vs. software support. Speaking from years of experience, supporting software applications becomes expensive very fast.
2 Likes
They’ve been pretty explicit from the beginning about Hubitat being a community code-friendly platform, but not really wanting to take on the oversight of what happens when some users take the entirely optional step of installing someone else’s code on the hub.
Hence, there’s no Hubitat app store.
Recently they have added a “developer plus” program, which has something to do with devs that want to charge for access to their code. I assume that involves some level of code review by the Hubitat team, but that’s an assumption. Since there’s presumably a financial arrangement with these devs, at least that would be time that Hubitat staff are likely compensated for.
1 Like
Absolutely.
The quickest way to grow HE is through community contributions, makes perfect sense.
HE cannot police that - they would get buried!!
BUT, I do believe they can build in baseline support to raise the bar going forward to help reduce risk going forward.
Even a community App that can scan Drivers and Apps for any urls/ip addresses/net calls and displaying them so the user can make a more informed decision would be a Great Leap Forward, obviously much better if is a built in tool.
This report would make no judgement - but if it flags an App that claims to perform zwave functions is doing external IP calls it should warrant a raised eyebrow.
This is extremely unlikely to happen. What you're asking is for Hubitat to have, and actively maintain a "pi-hole" type blacklist of addresses for IPv4 (and presumably IPv6) address space. Isn't the purpose of moving to Hubitat to eliminate a dependency on cloud devices?
My pi-hole database updates every 24 hours. Something like that would be the appropriate solution for your concern.
1 Like
@aaiyar no blacklisting required or suggested:slight_smile:
Just something that can perform a one time (on demand) detection and display (of IP addresses/URLs) any code in the Custom Driver/Apps installed.
If the app is a simple zwave monitor why does it need to go to xyzzy.com ?
The use of it is transparent now and the developer can easily provide justification or the user can take independent action.
No judgment or real time filtering, no black listing etc just a simple report that shows what an App or Driver is calling.
It is not a solution it is a step to allow non developers to use community Apps/Drivers with a slightly higher confidence level.
Someone could potentially make that.. But so what?
If I were malicious I could easily bounce traffic off AWS, azure, etc which can't easily be blocked as they are used by many legitimate apps/functions. Or I could use a generic proxy that is used by legitimate services, etc.
I just don't see a centralized review/scan of user code being effective for this purpose.
6 Likes
