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.
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.
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.
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…)
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.
Then why does the Security Policy strongly imply severe vulnerabilities will be fixed? You cannot secure house with front and back doorways but no doors!
The point I think is that the impact of malicious users controlling your things because they have unrestricted access to them can be seen as less severe as having crypto miners or botnet software installed on your machine without your knowledge because the exec add-ons offered easy arbitrary remote command execution as a feature. Hence CVE-2020-5242, and an unusual patch release with an unfortunate breaking change - because the disclosure couldn’t go out without a fix or contingency plan.
Yes, it is severe when when running OH as root, which some people do. However, it’s great to have a security policy in place.
However, I recommend to have an API-gateway together with an identity management in front of pretty much every API-build-backend. But that’s of course nothing for the ordinary home-user. That’s the reason why IT-security IMHO ends at the front door for most of us.
Maybe I’m thinking wrong, but Openhab is primarily a system for a smart house, isn’t it? How many people do you have in your house who have the intent and ability to manipulate your server? I think you should invest more time to make the system more user-friendly than manipulation-proof. Bring a surface that everyone can work with, such as the “Next generation design” project by David. This had so much potential and was destroyed by stupid arguments. Or also important things like the blue tooth binding, which was terribly neglected. Instead, the Tesla binding is celebrated. What are the priorities? If the collaboration and the focus on user-friendly operation do not change soon, then it is not surprising that more and more people choose the iobroker.