How secure is waveterm?

[x9sim9]

So this being an electron app which then talks to a backend service which runs the commands what kind of security is in place to make sure commands / keystrokes cannot be intercepted and a malicious app could not inject commands into the backend service when the current session has sudo privelleges?

While i love the potential of an electron app for customisation, considering how crucial shell is just wondering if it would create some severe security vulnerabilities

[sawka]

Will write up some larger security docs in the future, but I wanted to just address this at a high level first.

So, the basic architecture is the electron app talks to wavesrv (which runs on your local machine), and then wavesrv talks with waveshell servers on all of the remote machines you're connected to. I can address the security of those two links.

electron -> wavesrv: wavesrv runs an http and websocket servers on ports 1619 and 1623 respectively. they are bound to 127.0.0.1, so these servers are only listening on the loopback device. that's the first layer of security, in that it will not accept connections except from the local machine. next, there is an "authkey" that must be passed in the X-AuthKey header. It is a UUID that is written to ~/.waveterm/waveterm.authkey. If this authkey is not passed, then wavesrv will reject any request (the websocket has a similar protection, but implemented slightly differently because websockets do not process headers). This protects wavesrv from any process that is sandboxed and cannot read the disk (e.g. browser based applications and webpages or any other sandboxed apps, or applications owned by other users -- the authkey is only user readable, no group or all permissions -- 0600). So this provides security except against "root" (root can sniff packets from the loopback device), or from processes running as your user with disk access permissions. Note that a process running as root could exfiltrate your sudo password (which is true for almost any system given that you could attach gdb and inspect memory or run a keylogger), but the password cannot be read by a process with only disk access. This provides similar security to storing private keys (without passphrases) in the ~/.ssh folder, or AWS secret keys stored in ~/.aws/credentials.

wavesrv -> waveshell: all of this communication happens over ssh via stdin/stdout. So this should be completely secure (except against a process running as root which can sniff packets out of the SSH handshake and then inject its own data -- although at that point, your whole machine is compromised any any every terminal emulator would be completely compromised).

[x9sim9]

Will write up some larger security docs in the future, but I wanted to just address this at a high level first.

So, the basic architecture is the electron app talks to wavesrv (which runs on your local machine), and then wavesrv talks with waveshell servers on all of the remote machines you're connected to. I can address the security of those two links.

electron -> wavesrv: wavesrv runs an http and websocket servers on ports 1619 and 1623 respectively. they are bound to 127.0.0.1, so these servers are only listening on the loopback device. that's the first layer of security, in that it will not accept connections except from the local machine. next, there is an "authkey" that must be passed in the X-AuthKey header. It is a UUID that is written to ~/.waveterm/waveterm.authkey. If this authkey is not passed, then wavesrv will reject any request (the websocket has a similar protection, but implemented slightly differently because websockets do not process headers). This protects wavesrv from any process that is sandboxed and cannot read the disk (e.g. browser based applications and webpages or any other sandboxed apps, or applications owned by other users -- the authkey is only user readable, no group or all permissions -- 0600). So this provides security except against "root" (root can sniff packets from the loopback device), or from processes running as your user with disk access permissions. Note that a process running as root could exfiltrate your sudo password (which is true for almost any system given that you could attach gdb and inspect memory or run a keylogger), but the password cannot be read by a process with only disk access. This provides similar security to storing private keys (without passphrases) in the ~/.ssh folder, or AWS secret keys stored in ~/.aws/credentials.

wavesrv -> waveshell: all of this communication happens over ssh via stdin/stdout. So this should be completely secure (except against a process running as root which can sniff packets out of the SSH handshake and then inject its own data -- although at that point, your whole machine is compromised any any every terminal emulator would be completely compromised).

Thanks for the detailed reply, wave is becoming my favorite terminal so good to know its been built with security in mind.

[rodion-m]

Btw, have you tried Tauri? At least, its executable is less size. @sawka