Authenticate connection to editors

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]

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.

[subnut]

@stephane-chazelas

Can’t dbus be used for that?

NO