Authenticate connection to editors

[Roguelazer]

This plugin is potentially-dangerous to use on any multiuser machine (or on any machine where untrusted code may be running, either as your user or as nother user) since it uses a fixed default loopback port (one reserved by IANA for another company at that... 😢) and has no way of authenticating editor-servers with the browser. A malicious attacker with access to loopback could read or If you're interested in how other extensions have addressed this problem, you might enjoy 1Password's blog on the subject from 2015.

A simple option for non-Windows systems would be to look into supporting a unix domain socket instead of a loopback socket; at least that would give a modicum of protection against other users on the same machine (although no protection against malicious software running as the same user). I somehow doubt that Fx57 has an API for websockets over a stream-mode domain socket, but you never know.

A more complicated option would be strong authentication; on first-run the browser extension could generate a TLS keypair and require users to confirm a fingerprint in the editor before using websockets; the rest of the session could just use wss:// instead of ws://. This would probably be difficult for editor plugins that aren't written in a language that allows easy temporary addition to a TLS trust store and I don't even know that there would be a safe way to generate an RSA or ECDSA keypair from an extension (that sounds like a lot of webcrypto and is there even ASN.1 in webcrypto?), but it'd be pretty secure.

The way vimperator implemented this historically, of course, was to make a securely-named temporary file on disk and pass its name to the editor through exec args; this is much stronger protection (since the file was readable by only the current user and the name was hard to predict, which in turn makes it hard for an attacker to find). I understand that there's no longer a process management API, but if there's a way to copy the textarea to a file, you might still be able to exchange text data through a securely-named user-visible-only file and just pass the file name through websockets?

I'm not sure how likely an attack like this is, but there should probably at least be a warning that if you're on a multi-user machine and the other users are technically savvy and prone to mischief that this plugin broadcasts all of your edits in plaintext to them.

[fregante]

Thanks for raising your concerns. Keep in mind that this is a browser extensions so most APIs available are high level, I doubt I’d be able to pipe to a file while keeping performance high.

Ideally the extension needs a rewrite but essentially it’s abandonware at the moment: it works, but don’t expect changes that take longer than a few minutes.

What could the worst be? They steal some textarea content? The connection doesn’t happen until the user actually clicks the button, so i think one would notice if that doesn’t work.

[stephane-chazelas]

As I understand, the editor server allows anyone on the same machine to drive your editor. From a cursory look (at the gvim one) it's only meant to allow reading and writing a buffer, but it seems it should not be too hard to get past that and since most editors can do anything including run commands, that would allow anyone to run any command as you.

Just throwing some random ideas if unix domain sockets can't be used. Sorry if they don't make sense, I don't know much about chrome/quantum extensions.

Can't dbus be used for that?

Or could firefox and the editor server share a secret? For instance an environment variable that would be set to a random string by a wrapper script starting both firefox and the editor.

Or could firefox be started by the editor server and communicate with it with a pipe?

[fregante]

If the server can be abused, more protections can be added to the editor Extensions.

The secret sounds relatively easy to implement, however I don’t maintain any of the editor extensions so it’d have to be a group effort.

I don’t know what dbus is, therefore it’s not available in web extensions.

Or could firefox be started by the editor server and communicate with it with a pipe?

Too roundabout. GhostText should be 1 click away, otherwise just type in your editor and paste it in your browser.

[MartyGentillon]

You don't necessarily need to pipe the text through a file, just sharing a secret through the file could be enough.

[subnut]

@Roguelazer Forgive my bad english and my low knowledge of network security....

TL;DR

I have noticed, that if some application is already using port 4001, then other applications cannot connect to that port. So, my question is, is there any way to still receive the message without connecting directly to port 4001?

More detailed

Say there's a server running on port 4001 on my machine. Also, there's a client that periodically sends some data (in plaintext) to that server on port 4001. Now, if I want to run another server on port 4001 with the intention of stealing the data, I can't (ERROR: Port Occuped) because my server cannot acquire the port.

So, is there any other way (ie. without killing the already-running server) I can get the plaintext data that is being transferred from the client to the server? If yes, how?

[subnut]

@stephane-chazelas

Can't dbus be used for that?

NO

[fregante]

I don’t think any editor extension actually shows an error to the user about not being able to connect, so any software can act as a GT server before you open your editor and just receive the data. GT won’t do anything in your editor, but the other software already received the content from the browser.

Other than that, I don’t know if other software can read data flowing through an open port, so encryption of the channel might not be necessary.

I think GT-browser should only ensure, optionally, that it connects only to what the user wants. As the title suggests: Authentication.

This is a valid request, but I just don’t know how to securely implement it.

[MartyGentillon]

Honestly, the simplest way would be to have the editor, upon connecting, send a nonce across the connection. The user can then verify the nonce in the browser and encryption credentials can be created so that it can be automatically verified next time.

[fregante]

The more I think about this, the less I think this is useful. An authentication here would only be useful here if:

• a malicious actor can open a port on localhost before your editor does, AND
• the field you're about to activate has sensitive information in it

Both situations are rather rare so adding complexity here doesn't seem worth it.

If the field you're about to activate has sensitive information:

1. Clear it
2. Establish the connection
3. Paste the content in the editor that opened

This only takes a couple of seconds and ensures that nobody else can read the content.

[fregante]

If you're a Sublime Text user you can open a new issue:

• Show an error message if the port can't be opened

This way you will know if the connection will fail when you open the editor. If the editor can open the port successfully, you're in the clear.

If you don't use ST, you can open the same issue in the relevant repository, if applicable (not this one)