We (the openHAB community) need a clear approach how people report security issues. We don’t want secure related issues in our public forum. So we have to guide people how to report these kind of issues.
As a member of the Drupal CMS Community i want to share some links with you.
For the beginning we can start with the information “please report issues to security@openhab.org”. The circle of recipients should be responsible for non disclosure and documented to the public.
openHAB as a central component in a smart home has to be secure.
We should define possible risks first, maybe. Because right now openHAB stores passwords, credentials, service-tokens in clear text to disk and happily exposes them via REST if you kindly ask.
Thanks for posting this. Indeed this is an important discussion to have and I hate that I didn’t think of it.
I’ve moved the post to Development Misc (I think that’s a good place) and added security to as a tag.
Oh boy are there risks galore.
Imagine this scenario. User decides to expose OH to the internet with poor or no authentication (it happens sadly). User also has need to run some random script so added openhab to the sudoers with permission on ALL (again, it happens frequently sadly). Or perhaps they want to use dash buttons and need to run OH as root so they can sniff for the arp packets. This user just gave the internet root on their server. No hacking required. Even if you don’t have the Exec binding installed, it doesn’t take much fooling around in the REST API to find and install it. And now you can remotely through the REST API cause openHAB to run any command as root.
It’s one reason why I come out so strongly on those who want to DIY their remote access. Most (present company excluded) don’t understand the risks they are taking or how to set it up and monitor it properly.
I talk about this here as there is already a thread that discussed this very scenario. Not that it happened but that it could happen.
In addition to credentials, OH usually has your location stored as well. Not just the location of OH configured in OH or in Things from bindings like Astro and OpenWeatherMap, but Location Items telling where you physically are (OwnTracks, iCloud, IFTTT) at any given time.
The sensitive info extends to configs, Things, and Items. Probably Rules in a lot of cases but we can only be responsible for so much. Maybe there is something we can give the user to use though, like a sensitive information store to put some of this stuff.
But as long as we have no authentication/authorization built in security like this is outsourced to third parties (NGINX, Apache, or openHAB Cloud Server).
I like the idea and agree with the need for a process and mailbox to report such issues. CVEs would indeed be awesome.
But I completely agree with David, we need to do a full security risk assessment to see if there are somethings we can/should change architecturally to address some of the risks. Getting some authentication/authorization in place would be a good place to start.
Maybe we can set up a private area of the forum to discuss? Mail list? Something else?
I can describe you briefly how it works with Apache Software Foundation (ASF). As ASF is quite dated its process in many cases mailing lists are involved.
Apache does not limit how many mailing lists project have, but most of them follow this scheme:
users@ - for generic inquiry about usage
dev@ - for development related discussions, bigger refactorings, public chats about how to move code forward.
private@ - a mailing list where nominations and eventual arguments are solved
secuirty@ - vulnerability reporting, usually its aliased to private@.
After issue with reproduction criteria is reported via whisper channel project lead is responsible for confirming it. Once that’s done she or he communicates this back to project team on private mailing list where solution can be discussed. Author of report gets information that thing is confirmed and what’s expected date for resolution. There is no public record of security related bugs (especially critical ones) in public forums until they are solved and bugfix releases are published.
A dedicated security team periodically verifies if all reports been handled.
Here is quote from ASF:
Note: No information should be made public about the vulnerability until it is formally announced at the end of this process. That means, for example that a Jira issue must NOT be created to track the issue since that will make the issue public. Also the messages associated with any commits should not make ANY reference to the security nature of the commit.
My idea for beginning was to have security mailbox. Every new message sent on it would cause creation of topic in restricted forum area, however I am not sure if spam bots will soon not run over it. Its something to be verified in first place.
Thank you for your interest in that topic. I’ve read your comments and want to suggest, that we recognize that there is more than one topic. We should discuss the different aspects of security in different threads.
My intent here was to give a community member or an oh user a guideline to report a sercurity related issue. The flavour of the “how to …” for me is irrelevant. I can send emails, put in my informations in a form - in short: i follow the needs of a oh security team.
So one topic is: how to organise security related issues?
Who should be informed?
Who is responsible for the contact?
What are the minimum informations about the process we (the oh community) should share with the public?
A second topic is imho: how to handle security in a more professional way?
When, how and why we use CVE?
Security Workflows, non disclosure, update strategy …
A deeper documentation about the process and an invitation to participate
And a third topic: best practice for a secure OH instance.
root user on a server, processes …
attack vectors
code review, best practice, quality assurance
core, bindings, third party software
Please: open up your own thread for topic 2 and 3 and let’s find a way for the low hanging fruit of “how to report a security issue” in this thread
I’m not sure if this would be an Architecture Council issue or not but it feels like it could be. I definitely think we need to bring it up once the AC gets off the ground (soon).
Just to provide an update. I opened a discussion on the AC to see if this is an issue for the AC to address or not.
I also spent a few minutes on the CVE site and it looks like we would use MITRE as our CNA. They have a web form and will accept a PGP key to encrypt their response back to us.
Based on what kai and company have to say on the AC discussion I will try to pursue this in whatever ways I can.
