I’ve seen more than once poorly configured routers happily give every device in your LAN a routable IPV6 address making them effectively exposed to the internet at large.
To reiterate: this vulnerability meant that if you run openHAB 2.5.1 or lower, by default, everyone is able to run anything on your machine, with at most 5 HTTP calls (I counted) - whether or not you have the exec binding installed, because you can install it remotely as well. If you don’t think this is critically dangerous, then tell me what is. IMHO This is not even something that should be allowed over HTTP at all even if the API is behind some kind of authorization because the risk is too high. It circumvents every other protection you have to restrict access like SSH.
I “inaugurated” the new security issue reporting process with this and yes, it was my suggestion to introduce a whitelist for this particular case because it effectively protects everyone while only being (what should have been) a minor inconvenience for users of that particular binding. But the decision to consider the vulnerability severe enough, adopt the idea to mitigate it and implement it was up to the addon maintainers. Eventually a patch release was made, as it’s customary when you disclose a security vulnerability - there should be a path offered to fix it right away. So the process worked. It’s confidential in nature because that’s how you have to work when dealing with security issues, you don’t want to disclose the vulnerability while you’re discussing on how to fix it, that’s that responsible projects do.
Honestly, I don’t even know why we’re even having a debate on whether or not it’s a good thing to begin fixing obvious, almost embarrassing security holes like this that compromise your system. It’s important and it’s an uphill battle.
This is not how you do security…
Yes you might not have anyone in your home who can understand this vulnerability and use it against you, but have a look at here in the forum and you will see that a lots of people who don’t know anything about IT in general, they just love their smarthome and use the tutorials and guides here and online to make everything up and running… Which sometimes involve that they just open up ports on their firewall, to easily access openHAB. Meaning that literally everyone on this planet can access your openHAB instance, thus use this exploit to execute anything on your server…
Or if you just use some older router which does no longer receive any updates for security issues, even without letting anyone in through the internet, your network (including your openHAB server) can be compromised.
From a user point of view I also see that openHAB is not that straightforward and easy to understand and use, but security is more important than this. And also don’t forget that a system which is that complex as openHAB will not/can’t be that easy to understand. Have a look at Home-Assistant which has a much simpler/newer dashboard than openHAB, still you need to read several docs to understand how it works and how you can set it up and customize…
Anyway openHAB 3 release is getting closer and closer, meaning at least some of your problems will be solved with that one.
And the published Security Policy says they will fix issues in 2.5 depending on severity. That means either high severity issues will be fixed or the Security Policy is null and void.
And for the record, if Yannick had not, I would have.
Great minds think alike. ;-D
You’ve made it clear you think this is important. Have you submitted it? Have you found someone to work on it? Have you offered a bounty? Have you gone to the issue on OH core and commented about it? Have you looked into the code and tried to solve it?
Ultimately, OH 2.5 core is frozen. Adding authentication requires significant and breaking changes to the core. The fact that they are breaking changes already means adding authentication would be an OH 3.0 feature, and luckily for us it is being added to OH 3.0.
2.5 bindings are not frozen. The above security patch was for the Exec binding. That’s why we saw this white-list change and why we won’t see authentication added to OH 2.5 but will see it added to OH 3.0.
Fixed it for you.
As the currently officially available version is 2.5.x, security patches will be considered for it, depending on their severity.
High consideration doesn’t mean “will fix.” But again, know a developer willing to take a crack at it? The issue has been open for years. Several developers have already tried and failed. Find someone to give it another try or accept that it will not be fixed until OH 3.
If I had to classify vulnerabilities in order of severity (there are standard ways to do this but still) I’d say:
an attacker gaining access to the system, or manipulating files beyond openHAB’s scope
leaking sensitive information like passwords over the API
misusing openHAB itself - reconfiguring it or getting info/manipulating devices that openHAB controls
Authentication/authorization is the only solution for 3., which is clear isn’t coming until OH3 (and you can always put a reverse proxy in front of openHAB, it’s documented), but I believe at least 1. (and maybe 2.) should be addressed to the best of our abilities regardless, and ideally backported to 2.5.x too.
check the git hub for that binding, there is a ton of work going on by a number of developers
there are tons of new bindings being developed
a face recognition system just got revived
tons of OH1 bindings are being updated
these developers are flying man
I tried to fix that several times. The support I got from the reporters was limited. There seems to be an issue with the native code, but I still don‘t know if it fails in situations where it worked before or not. And I mean on the exact same hardware, with the exact same Linux distribution and different OH versions only.
There doesn’t need to be an exclusion stated nor any other list of exclusions or inclusions described to the Nth degree. The policy states that security patches will be considered.
I’m quite late to the party but want to make a comment anyway.
Isn’t this the purpose? Reagarding IPv4 NAT and dynamic IP were a mechanism to get more addresses and “security” was a side effect so that nothing would be directly exposed. IMO today when a router is poorly configured it’s missing a proper firewall and so is your devices. IPv6 gives you speed, reliability, and proper routability but ofcourse it comes with a small cost. Users need to know what they are doing. I don’t understand why people are so much against new technology. And at the same time I understand why IPv6 usage doesn’t grow as it should.
@Kai do you have any plan when to release the next Patch Release?
If it will not contain any Core update, how you will be able to update the addons? Just one-by-one uninstalling and installing them again? Will there be any little tool which can do this?
So new packages will be built, just with the old Core? AFAIK, the addons are not included in that package you install with package managers, these are downloaded on the fly.
That’s what I meant - some ISP routers “boxes” that I’ve seen are lacking a firewall and have IPV6 enabled by default, makes router advertisements and have built-in DHCPv6 servers that you cannot even disable if you run your own. In that case your Raspberry with openHAB on it gets an address which you can reach from anywhere on the internet and you might not be aware of it… I’m not saying IPV6 is bad it itself but it’s harder to understand
