domterm 2.9.4 --port doesn't work and is very serious security issue
psb777 opened this issue · comments
I downloaded the 2.9.4 AppImage.
I'm running Devuan Daedalus (i.e. Debian Bookworm without systemd) on my desktop
There:
$ domterm --port 8080 new /bin/bash
On a local browser (uptodate Chrome)
http://localhost:8080
gives blank screen (i.e. no bash interaction)
and
http://localhost:8080/etc/passwd
displays /etc/passwd file
Note that $ domterm new /bin/bash works.
Hmmm. The "server" (i.e. --port) feature has clearly gotten a bit bit-rotted. I'm looking into it.
If I want to run a terminal in Firefox (for example), I normally just do:
domterm -Bfirefox
Combining a port specification with a new command should probably be an error. The new should happen implicitly when you browse to http://localhost:8080. That used to work, but got broken at some point.
Interpreting http://localhost:8080/etc/passwd as "return the contents of etc/passwd" is a bug. However, it's not clear to me that there is a "very serious security issue" - more than creatng a terminal would be. If you create a terminal in a browser, that terminal has the permissions of the user that started the server. And that user can read /etc/passwd. That said, the documentation should be much clearer that you be very careful about starting a listener, doubly so on a multi-user system or if the port is publicly accessible.
It would probably a good idea for the documentation to include a recipe for how to set things up so the terminal session starts with a login prompt. If you have a suggestion, it would welcome.
I fixed the "security issue" part of the bug report. I.e. the http server will no longer respond with local files unless the request contains a matching randomly generated server key.
The fix is in the github sources. I'll upload a new AppImage after I fixed the --port feature not working.
I've commited some fixes so --port works again. There are still some issues: the --port feature needs some polishing. It is not the "normal" way of using domterm. If you have a use case for domterm-as-a-service I'll be happy to work on the necessary polishing, but I need to have a better understanding of the use-case.
I still haven't updated the documentation or the AppImage.
I'm aware of the shell-in-a-box project, without having looked closely at it. Is that the sort of functionality you're looking for?
Hello! Thanks for responding. Understanding the use case?
If
$ domterm new /path/command args
has a use case then so must(!)
$ domterm --port 8080 new /path/command args
I do not understand why one of those should be considered "normal" and the other in any way unusual. Let me tell you about this thing called the Internet :-)
I would like to use domterm remotely just like one can use it so well locally but here are my two immediate
use cases:
- I have an old fashioned plain text console/terminal interactive app.
- I have a few very clever Unix-style filters which extracts/parses very useful information out of plain text.
These I would like to expose to new users on the web.
I tried to use shell-in-a-box and abandoned it for a reason I can no longer remember. But even were I to get it it to work "domterm" is better, or would be! I have tried so many of the supposed solutions to this problem and they all (it seems to me) have issues. The only one (I've been able to get working) requires a ssh login and this extra layer is entirely unnecessary. It's wssh confusingly renamed to webssh (at least one other thing called webssh exists) and it can be found here https://pypi.org/project/webssh/
I like domterm very much. The docs read as if anything possible locally should be possible remotely. If there's a quick fix I would really appreciate it. Thanks for all your good work!
http://localhost:8080/etc/passwd - the reason this is a serious security bug is that http://remotehost.com:8080/etc/passwd also works. But having local users being able to read any readable file is also not a good idea. A user is not normally someone with shell access. Normally a computer user is someone tied into a particular interface or a particular application. domterm isn't only useful for systems programmers.
domterm-as-a-service ? It is a service! And a very good one. Some may want to use it to access the app /bin/bash and others may want to use it to access the legacy dumb-terminal app 1990ConsoleAccounts24x80. Others may find my app /usr/loca/bin/clever-filter.sh useful, and from anywhere on the Internet.
Here is an interesting (I think) "service" which I've made available via the Python webssh/wssh. The intervening ssh is entirely unnecessary and itself provides a security problem in that a general ssh login screen can easily be provoked to appear:
Chatbots using OpenAI's GPT via TuneGPT
This would be somewhat nicer were it enabled by domterm.
the reason this is a serious security bug is that
http://remotehost.com:8080/etc/passwdalso works
My point is that if you can create a shell with http://remotehost.com:8080 then you can cat /etc/passwd inside that shell. So I'm not convinced it's an additional security problem.
Regardless, it's fixed.
Thanks for the fix. My point is that zero or very few of those elsewhere on the Internet - anywhere from which remotehost.com can be accessed on port 8080 - should be given shell access at that URL. And likely are not! /bin/bash is not the service made available on a public server and for the same reason they should not be able to read /etc/passwd at http://remotehost.com:8080. But they could do so. It's difficult to think of a more serious security flaw. Thanks again for the fix.
The use case for
domterm [new /path/command args]
is basically the same as:
xterm [/path/command args]
However, domterm has a lot more features, such as embedded graphics and rich text (html).
DomTerm supports many different browsers, both "embedded browsers" (Electron, Qt, Wry) and regular desktop browsers (Firefox, Chrome, Safari). The embedded browser are a little nicer; using a desktop browser has fewer dependencies. So you can do any of:
domterm -Belectron
domterm -Bqt
domterm -Bbrowser
domterm -Bfirefox
etc
Using -Bfirefox or -Bbrowser does open a browser window on localhost:PORT, under the hood. However, it does so in a more secure and more convenient way.
Yes, you can create one or more terminals by explicitly starting domterm with a --port argument and then manually typing localpost:NNN. However, that is not my recommendation, and I don't see any benefit. It's less convenient and less secure.
Being able to run a shell or other command on a remote system definitely has uses. However, setting things up in a secure way as a service with ssl is non-trivial. Instead, domterm offers what I think is a very nice "wrapper" over ssh. That is what I recommend for someone wants to be able to connect to remote systems that they have accounts on, assuming they can copy over an executable domterm (in a private location, no super-user access needed).
The use-case of "shell-in-a-box" is for when you want to allow people to connect to your server, just using a browser, and without them having to install any local software. This is useful, but it's more complicated to set up: you have to figure out how to do so securely without being able to piggy-back on ssh.
To use domterm in basic shell-in-box mode, running CMD ARGS, do:
domterm --port NNN shell.default='CMD ARGS'