Security concerns: Karaf console SSH listening on all interfaces by default!?

Setup, Configuration and Use Installation
,
1
  • Platform information:
    • Hardware: Raspberry Pi 4 Model B Rev 1.1 w/ 4GB w/ 64GB Samsung PRO Endurance SD card
    • OS: openHABian v1.7.1 (Raspbian GNU/Linux 11 (bullseye))
    • Java Runtime Environment: OpenJDK Runtime Environment Zulu11.52+13-CA (build 11.0.13+8-LTS)
    • openHAB version: 3.2.0 Release
  • Issue of the topic: Insecure defaults for default Karaf console network interface

The default network interface for the Karaf console appears to be 0.0.0.0 (all interfaces) rather than the expected 127.0.0.1. My etc/org.apache.karaf.shell.cfg, had sshHost = 0.0.0.0 without any explicit changes from me. I guess I canā€™t rule out something changing this automatically (such as through openhabian-config) but I had no indication this was changed from the default. I also noticed in services/runtime.cfg that org.apache.karaf.shell:sshHost = 0.0.0.0 was already uncommented, again without any explicit changes from me.

This is counter to what is stated in the documentation (The Console | openHAB) and represents a security risk, since there is much less awareness of this or the need to change the password there.

I noticed this while using the Karaf console to make some changes to the log level while troubleshooting something unrelated. Out of curiosity, I tried connecting to that port directly from my desktop and, to my surprise, it worked :open_mouth:

I see from posts like this (Change of org.apache.karaf.shell.cfg by OH3 update?) that making changes to the org.apache.karaf.shell.cfg itself isnā€™t a good solution since these can be overwritten by updates and that changes should go in services/runtime.cfg. Not sure where this change was introduced but if the openhab project doesnā€™t control what goes in org.apache.karaf.shell.cfg, maybe the expected default of 127.0.0.1 should be set from runtime.cfg automatically, out of the box, to avoid unexpected changes.

I went ahead and changed it to 127.0.0.1 in both places on my system just to be extra sure, and that did the trick. I can no longer reach the karaf console from outside localhost.

Like I said above, I did not make any explicit changes to these files before finding this, but I did run various routines within openhabian-config, such as updates (donā€™t remember everything there). If these settings truly arenā€™t the default, then something there was likely the culprit but this was not at all clear when I ran them.

For whatever itā€™s worth, runtime.cfg in the openhab-distro repo does appear to have this line commented out (openhab-distro/runtime.cfg at main Ā· openhab/openhab-distro Ā· GitHub) Not sure if thatā€™s the correct place to be looking though.

Iā€™m not sure if this is the correct category for this post but since this appears to be an issue with the defaults, the installation category seemed like the closest fit. (Feel free to move this if you think it should go somewhere else) I would have reported this on github but it wasnā€™t clear to me what repo it would belong under.

The purpose of this post is to alert people to check this on their install and hopefully get this changed so that people arenā€™t unknowingly leaving their Karaf console SSH port open on their network with default credentials.

2

Beware of absolute statements on security without proper context and evaluating trade-offs.
Risk depends on various details such as if youā€™re connected to the inet and what your OS security measures are etc

This is tricky as thereā€™s multiple components involved, to overlap, written by different people (OH itself, openHABian and the docs).
The docs on console are part of openhab not openhabian so it is meant to apply to everything such as OH on a self-installed Ubuntu or Windows of yours as well.
I donā€™t know if the implementation has changed recently but I think it still comes with the localhost restriction.

openHABian however will remove that because of a tradeoff in useability vs. security we made there. Note that this will not happen if you donā€™t use openHABian so the console docs is still correct but any reader has to apply the proper context.
Agreed thatā€™s difficult, but with so many options on OS and configuration and various OH subprojects involved, even I wouldnā€™t know where to best document stuff like this that ā€œconditionallyā€ applies.

PS: Maintaining docs and even more so consistency across is an incredibly tedious piece of work noone wants to do. And many users donā€™t even read the available documentation that we have put so much work into.
cc @Confectrician

3

I canā€™t provide a good recommendation for a general solution on how to deal with conditionally occuring contents for the docs.

Anyhow i would say the openhabian docs would be the correct place for mentioning that something has been implemented on purpose in this case, since the setting differs from the base system

4

Thank you both for your responses. I can appreciate that this isnā€™t necessarily a security issue for everyone (hence calling it a security concern in the title). I could have probably worded that better within the post though.

I donā€™t know the specific rational for making this the default for openHABian vs standard openHAB but would hazard to guess that most people using openHABian donā€™t realize this is the case and likely havenā€™t taken any explicit measures to isolate it from other, potentially less secure parts of their network. The comments in runtime.cfg even treat this as a notable concern with ā€œ!!! Security Warning !!!ā€ and a reminder to change the password next to that line. Since you can get to this console on localhost from the normal system SSH shell, leaving it open on other interfaces seems unnecessary to me. I can accept that there are reasons that donā€™t match my specific use-case though.

Documentation differences aside, I would argue that the Karaf console password should be treated in a similar way to the openhabian system user password, where openhabian-config checks to make sure it isnā€™t left as the default. This way users wonā€™t be left unaware that thereā€™s something hanging out there with an open port and a default password. This would also help when people arenā€™t as careful about reading documentation (once updated).

BTW, I totally appreciate all the work you all put into the documentation! OpenHAB has such a large scope of capabilities and features that I can hardly imagine how I would have gotten started without it. Of course these forms are a great resource too but the value of clean, focused documentation canā€™t be overstated. I realize documentation is kind of a never-ending and thankless task though. As new features are added and changes are made, itā€™s easy to see how that can fall behind in areas.

Could you provide a bit more insight into why this change was made only for openHABian? Iā€™m not ready to commit to being a ā€œdocumentation personā€, but with a bit more background on this, Iā€™d be willing to take a stab at writing up something about this for the openHABian documentation, to help communicate this there.

5

As I said itā€™s a tradeoff that was intentionally made. Yours is the security first approach which is found among IT guys and important to a minority of people only (and those know how to evaluate and change it, right?). Some people would even call that paranoid.
The average openHABian user will not care or know and will not read the docs or will stop doing so latest when he hits the ā€˜securityā€™ headline.
But (s)he will suffer from console to not work right away, complain and ask for help, resulting in even more work to us volunteers. So all things considered, default open is clearly the better choice.
Note it isnā€™t authentication being turned completely off, thereā€™s still the password.

The alternative would have been to do it in the distro i.e. it would have become the default for everyone. As the distro doesnā€™t know the OS it gets installed to, ā€˜offā€™ is reasonable to avoid security holes on anything where the user does not actively take care of this and in line with the rest of OH (you donā€™t get any functionality unless you actively set that up).
openHABian then again is the OS so we know the setup a lot better.

1 Like
6

I appreciate the follow-up response. Youā€™re assessment of my perspective is pretty close. I certainly donā€™t want to dissuade anyone from using openHABian. Just trying to help. Since openhabian-config already has provisions to check for a default system password, I imagined that adding a check for a default Karaf shell password wouldnā€™t be any worse, and would help in a similar way.

For what itā€™s worth, as one of the smaller subset of users that find these details important, I would have preferred to have found out about this from the documentation rather than through experimentation and through our discussions here. Not a slight on anyone; I totally appreciate the challenges of maintaining documentation like this and appreciate your time responding to me about it.

If thereā€™s any interest in having a note about this in the openHABian documentation, Iā€™m up for drafting something this weekend for consideration, keeping what youā€™ve said in mind. If thereā€™s no interest, I donā€™t want to waste time though. Not looking to be alarmist there either. Just want to lay out how it is based on what youā€™ve expressed here and point readers to instructions for changing the the Karaf network interface settings and/or password if they are so inclined. I understand too that you reserve the right to modify it or not use it at all as you see fit.
To make sure weā€™re on the same page about where this would go, this is the page for openHABian specific documentation that Iā€™m aware of: openHABian | openHAB. If thereā€™s somewhere else for this that Iā€™ve missed, could you point me there?

7

The source for that web page is here and you can create your text as a PR on Github.
Keep it short and Iā€™d not like you to open another full paragraph on security or similar so look for a headline this fits under best.

8

FWIW, updating openhab package replaces .cfg and console is inaccessible by default again.
Worth mentioning I guess

9

Just wanted to let you know I havenā€™t forgotten about this and Iā€™m still working on it in the background.

Thanks for this info about changes to the config during updates. Iā€™ll be sure to include that detail.

For what itā€™s worth, it would be nice if there was a notice of some sort during an update if a modified config file is about to be replaced. From a security perspective, at least in that case itā€™s locking down the interface vs. silently opening it up. Based on the stated reasons for leaving it default open however, that sounds like it might lead to confusion for some users.