openHAB 2.5.x Patch Releases

All, we have just published the patch release 2.5.2 - see its release page for details!

In constrast to the original plan stated above, there is again a distro 2.5.2 available, although the distro itself is more or less identical to version 2.5.1 since all changes only concern the add-ons.

This also means that the 2.5.2 patches are directly available to any 2.5.1 distro installation as well without doing a distro update. If you install new add-ons - or you delete the cache and have add-ons reinstalled - the distro will pick the latest patch version of the add-on.

IMPORTANT NOTICE TO USERS OF THE EXEC BINDING:
Due to this security advisory, the exec binding requires to have a whitelist of allowed commands to execute. Note that when updating the exec binding to version 2.5.2, it will stop functioning until you provide such a whitelist. Please see the binding documentation for details and also check this post for a detailed how to.

13 Likes

9 posts were split to a new topic: Security limitations in 2.5.2 exec binding

Because I was a bit confused how to update from 2.4 stable to 2.5 stable I was waiting until 2.5 is really stable. I guess now with 2.5.2 it is.
How do I get now that 2.5.2 correctly installed, just via the GUI?

Thank you, Kai! Will there be a separate announcement for 1.x addons? (nudge)

3 posts were merged into an existing topic: Security limitations in 2.5.2 exec binding

Regarding the security vulnerability: it might be interesting to mention that following an initative by the architecture council, openHAB now has a Security Policy and participates in the Common Vulnerabilities and Exposures (CVE) program. You can report vulnerabilities to security@openhab.org and they will be discussed privately until a security advisory and CVE are eventually published.

This remote code execution vulnerability (CVE-2020-5242) involving the exec addons is actually pretty nasty so now that it’s out there, all users are strongly advised to upgrade to 2.5.2 whenever possible, even if you don’t use the exec binding or transformation.

7 Likes

Was there any reason why there was not at least an attempt to read in current exec definitions from the JSONDb to initially populate a whitelist? That could have eased many upgrades.

1 Like

The advisory board now believes openHAB should be secure. The openHAB now needs authentication doors to secure its entrances.

I guess we will see an authentication update for 2.5.x. Lack of any authentication has always been the largest and most severe OH security vulnerability. If there were authentication and authorization then this whitelist may not have been necessary.

6 Likes

This would be great.

With the REST API and WebUIs, Items and Things can be discovered, added, changed, & deleted without by any unauthenticated user. Considering they are acknowledging unauthenticated access to the REST API (and I assume, the WebUIs) I see only 2 possibilities

  1. Remove all UI & API management capabilities, reverting back to text file & CLI configuration

  2. Add authentication to OH.

1 Like

Adding authentication would enable creation of roles and users. Imagine access-restricted sitemaps!

2 Likes

That’s actually a good idea, and it’s not too late.
Install jq with apt-get or similar, create a new misc folder in your configuration if it doesn’t exist and “cd” to it, then:

  • To put all commands of existing exec things to the whitelist, this command should work:
    curl http://localhost:8080/rest/things | jq -rM '.[] | select(.UID | startswith("exec")) | .configuration.command' | sort | uniq >> exec.whitelist

  • To put all commands when the exec transform is used as a link profile in the whitelist, this command should work:
    curl http://localhost:8080/rest/links | jq -rM '.[] | select(.configuration.profile == "transform:EXEC") | .configuration.function' | sort | uniq >> exec.whitelist

Note, you might have other instances of EXEC(commands) directives in other places to perform transformations (thing configurations like MQTT, item labels…).

9 Likes

Only if they add authorization too. Really they should add accounting so you know what a user did too. Together they are normally referred to as AAA

1 Like

The user community occasionally has useful ideas… :rofl: :roll_eyes:

Indeed. There’s already an audit.log file which could support the accounting purpose.

Without authentication, you do not know WHO did something though.

I didn’t mean to imply otherwise.

1 Like

I was taking authentication for granted when you were referring to the triple-A… They’re actually a dependent trio.

1 Like

Obviously, exposing your OH instance the the internet without a decent form of authentication is a bad idea, no matter what security patches/updates you apply…

Having said that, I realize that there is currently no easy setup for a secure internet-connected OH setup. Using your own openhabcloud instance comes close, as does a more robust setup of an authenticating (not basic auth!) reverse proxy. But I guess that is not doable for the majority of users. And it does not protect you from DDoS or 0-day attacks.

Authentication and authorization is definitely on the list for OH 3. I doubt we will see that added to 2.5.

It’s not like suddenly security has come up and it’s never been thought of before. It’s just that we finally have a process in place to submit, discuss, and fix security related issues in a private way before releasing “here’s how to hack openHAB” to the world. This exec binding fix is just the first one we submitted through the process to see how it works.

The lack of authorization and authentication is well known and being worked and as far as I can tell will be there for OH 3, but if you have any other security related concerns please do submit the issue to the email Yannick has in his post above.