we are a team of four students currently doing a Master’s Study. In one of our courses we write a scientific paper on openHAB with a focus on delivering a thorough threat model of the system. Specifically, this means that we take advantage of already existing threat modeling frameworks (here: Hybrid Threat Modeling Method, considering SQUARE, Security Cards and Personae non Grata) and use them to analyse openHAB. In the end, we want to produce a paper that does not only fulfill academic requirements, but also provides interesting pratical insights for you, the community, developers and users.
However, what we do struggle with at the moment, is the static code analysis (which is part of our research method). Because, unfortunately, none of our group-members has the technical understanding to do it.
And this is where we would like you to join our discussion.
For the beginning, we would like to ask you some questions on the openly available source code of openHAB. Please feel free to answer them, and also ask questions on our project, if you are interested.
Questions for the Community:
Are there any threats / bugs / errors you came across with in the code of openHAB over time?
What were these and how did you, or the community, mitigate them?
What could have gone wrong?
Were these occurrences reported and recorded? If yes, where?
Of course, we are willing to publish our paper after officially handing it in (July).
Thanks in advance, your efforts are more than just appreciated.
Not ATT&CK? Joking. I have a personal connection to the ATT&CK framework, though I’m not sure it would apply here.
Yes of course we’ve had vulnerabilities.
The log4j2 issue from a few months ago (CVE-2021-44228) hit us. A thread was opened immediately, discussion took place to determine how it impacted us and within a couple of days mitigation was deployed and back ported to older versions (you can see the discussion on the forum in various places but mainly Log4j vulnerability.
Another issue to note was one of design. The Exec binding allowed openHAB to execute arbitrary commands on the operating system. Since OH 2, the Exec binding could be configured from the web interface and the web interface had no authentication/authorization at that time. So anyone with access to OH over the network could execute any command on the OS. This was mitigated immediately by implementation of a whitelist mechanism (only commands in a preconfigured white list are allowed to run by the Exec binding) which can only be configured via a text config file. So only someone who has already got access to the machine OH is running can configure is so that Exec can run the command.
Later on in OH 3 some authentication/authorization was also added to OH overall so only someone logged in as an admin user can create/modify a Thing through the web UI. The whitelist remains so now this issue has two mitigations in place.
OH also has a mechanism to report vulnerabilities in secret so that discussion and mitigation can take place before public disclosure (standard GitHub process, see the readme on any of the GitHub repos). I think the Exec binding issue was that mechanisms first use. The Log4j2 issue didn’t go through that and instead was all discussed in the open on the forum.
I don’t have insight into what other issues may have been reported through that mechanism and their ultimate outcome.
And while this might be a bit pedantic, terminology is important here. A “threat” is some actor (could be mother nature, not just people) that wants to attack a system. A “vulnerability” is a flaw in the system that a thread can exploit. The two issues discussed above are vulnerabilities, not threats.
And in both cases, the software was working as designed so they are not bugs or errors (unless you call lack of foresight an error). In the log4j2 case, it was a feature added to the system that wasn’t terribly well thought out.
In the Exec binding case, it grew out of a combination of two independently implemented features without considering the impact they each have on each other which isn’t surprising since it was totally different developers working in separate repos. The Exec binding has existed for a long time before OH even had a REST API but it was reimplemented shortly after OH 2 was released (OH 2 introduced the REST API). When it was reimplemented, the primary focus was creating something with the same or more features compared to the old implementation. It took some time for someone to put the two together and realize there was a problem.
With regard to bugs / errors you may have a look at the issue reporting via github for the core software as well as for the addons.
As OH uses opensource / mvn repositories a link between vulnerabilites and OH ( in the used libraries ) can be found via mvnrepository artifact logging e.g. : https://mvnrepository.com/artifact/log4j/log4j
