I agree that security issues should be pointed out, but in this case it’s not relevant. First of all openhab don’t use nginx. It can be installed from openhabian-config, as an optional component (which many do), but openhab itself has nothing to do with nginx. Second, the vulnerability is connected to php, which openhab doesn’t use at all. So you can sleep easy!
As mentioned, the linked to CVE is completely irrelevant to OH. OH doesn’t run on nginx and OH doesn’t use PHP.
There has been a lot of discussion and work about how to handle security related discussions concerning OH and there is work to set that up. But it was agreed by the maintainers with the consultation of the AC that using an open discussion forum like this is not how we want to have security issues reported and discussed. We are working through the options right now to decide how that will work (reporting email address, a way to discuss the issue among the developers that is kept private until the problem is fixed but open enough to include the reporter themselves and other relevant developers, etc).
Security has not been ignored but unfortunately it’s not at the top of the priority list either. But OH, in it’s current implementation should be assumed to be insecure and not be directly exposed to the Internet or other dangerous networks under any circumstances. OH provides the myopenhab.org service for those who do not possess the skills and time to safely expose OH through a reverse proxy like nginx. For those with the skills and the time, we provide instructions for how to set up nginx or apache as a reverse proxy, but monitoring the CVEs on the reverse proxies as well as monitoring those servers themselves is among those skills and time you are expected to possess in order to deploy OH in this way safely. Or, as a better alternative, we provide the openHAB Cloud Service as a package you can install on the cloud provider of your choice if you don’t want to rely on the openHAB Foundation’s instance.
I don’t think we can or should take on the responsibility to announce every vulnerability to everything that OH might be running on or might be running along side OH. It’d be a full time job and honestly most of the CVEs that get filed like that are no big deal for those running a default install of OH behind a firewall. For example, a CVE like the one linked to requires local access to the machine to exploit. If you already have an attacker on your machine, this CVE is the least of your problems. And the mitigation against this CVE (for the typical home user running OH) is to just prevent people you don’t trust from having access to your machine.
“But why post something that, it you even gave it a cursory glance, is off-topic for this forum??”
Off topic, for the forum called off-topic? Hmmm. That’s a bit befuddling to me.
“I don’t think we can or should take on the responsibility to announce every vulnerability to everything that OH might be running on or might be running along side OH.”
Well, I respectfully submit that’s what it takes to keep your user community aware of threats to their systems. You might annotate the alert as low risk and why its low risk, so users can make an informed decision.
“Security has not been ignored but unfortunately it’s not at the top of the priority list either.”
Its difficult to accept that its “not been ignored” when the forum for discussion of the app has no forum in which to discuss security issues, or for users to search for relevant alerts, applicable solutions etc. And when I do post something, albeit perhaps incorrectly attributed to Openhab associated app, I get potshots for posting something off-topic in the section annotated as “off topic”.
This thread was started in honest attempt to provide possible alert. Turns out that the alert was arguably not relevant, apologies.
So are you volunteering to make an announcement every time there is a CVE filed for:
All variants of Linux
OSX (all currently supported versions)
Syology (all currently supported versions)
QNap (all currently supported version)
anything connected to the over 350+ supported bindings
If so I wish you all the luck in the world. I’d rather contributors to the project contribute to actually addressing security issues that reside in the code that we actually control.
We have made a conscious decision to not have an open forum to discuss openHAB issues in the open so that the security issues can be corrected before they are announced to the world at large. This is common practice across other open source projects and commercially. But we are working to get the whole path off the ground. It’s not there yet. Once it is off the ground, then yes, we will announce security problems and mitigations or fixes for them.
Reposing CVEs here is not going to address this. They will still have to search on this forum to find them. And we won’t even have the relevant information here for most of them. I won’t block anyone from volunteering to take on this mammoth task and I’ll even volunteer to do a little bit myself. But given the degree of effort required, the fact that it’s all duplicated effort as this will all be listed and announced elsewhere more efficiently and with more detail than we will be able to do, I don’t see how we could ever approach taking on this task and even come close to achieve something that is both timely and achievable.
I’m totally on board for doing this for the code that we actually have control over. And we are working to build that.