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
-
Remove all UI & API management capabilities, reverting back to text file & CLI configuration
-
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… 
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.
Quote from the Security Policy:
As the currently officially available version is 2.5.x, security patches will be considered for it, depending on their severity.
Lack of AAA authentication is very severe. Unauthenticated users are free to add, delete, & manage Items, Things, & Rules both through the WebUI and the REST API. If these are not vulnerabilities, then neither is CVE-2020-5242.
1 Like
Then submit an issue through the security email. But the lack of auth and auth isn’t something new. An issue has been open for it since before OH 2.0 was released. There were at least two aborted attempts to add it over the years IIRC, both of which ran into some sort of problem and failed. Adding this will almost certainly be a breaking change. Given the history I just don’t see how it will be feasible to add it to OH 2.5, no matter how much you want it.
But as with everything, code speaks louder than forum postings. You or anyone else is welcome to make a third attempt at adding it to OH 2.5 without breaking too much if you can.
Not every security vulnerability gets fixed and if they do get fixed, they don’t necessarily get fixed for all versions of the software.
I myself have a security issue that I submitted yesterday that in all likelihood won’t be fixed in 2.5. There appears to be no way to fix it in 2.5, but already made/planed for changes to OH 3 will address it.
Hi guys,
After exec binding upgrade it does not work for me.
I am running openHAB on RPi and:
echo $OPENHAB_CONF
/etc/openhab2
I have created folder ‘misc’ in /etc/openhab2 and then ‘exec.whitelist’ in it.
In ‘exec.whitelist’ I put:
/home/openhabian/script.sh
In exec.things I have:
Thing exec:command:command1 [ command="/home/openhabian/script.sh" ]
When running it from sitemap I got en error:
[ng.exec.internal.handler.ExecHandler] - Tried to execute '/home/openhabian/script.sh', but it is not contained in whitelist.
What I am doing wrong? How to troubleshoot it? I have only try to reboot openHAB but it does not change anything. It was working before the upgrade.
I agree, so actually CVE-2020-5242 was probably an over-reaction here as clearly any access to the REST API exposes everything and must not be allowed to unauthorized people. We clearly state so in Securing Communication and Access | openHAB.
Note: As @rlkoshak mentions, for openHAB 3 authentication&authorization is clearly on the roadmap. It won’t be shipped without. There’s just no way to retrofit it on 2.5.x.
2 Likes
Well, at least we have security ‘front and center’ for a broader audience again (as far as that was needed in the first place) and I suppose it was a good way to announce and test the Security Policy. 
But seriously, I think it is a good thing that the Foundation is making these steps and IMHO the openHAB future is starting to look brighter and brighter! (Can’t wait to test OH 3 snapshots…)
Hi @kristofejro, have a look at Security limitations in 2.5.2 exec binding for some ideas.
What worked for me is that I had to “touch” the $OPENHAB_CONF/misc/exec.whitelist file after openhab had restarted. I have to do this on every restart.