Purpose of secure_cookie in Electron.jl

Specific Domains Web Stack
,
1

When Electron.jl launches a new electron process, it passes a secure cookie which is then used to authenticate the electron process when it tries to connect back to the Julia process. I’m not sure I understand the purpose of this, for several reasons:

  • The cookie is passed on the command line; hence it can be seen by many other processes on the system; hence it isn’t really secure.
  • The cookie authenticates the electron process to the Julia process, but what about the other direction? If someone manages to impersonate the Julia process, they can send arbitrary JavaScript to the Electron process and thereby potentially gain access to privileges they weren’t supposed to have. (Disclaimer: I don’t understand all the details of OS privileges, so it’s possible that this point isn’t really a problem in practice.)
  • Blink.jl seems to be doing just fine with no authentication at all. What is different about Electron.jl that Electron.jl needs authentication but Blink.jl doesn’t?
2

An interesting question. Answering these questions is what git blame is good for :slight_smile: ( https://github.com/davidanthoff/Electron.jl/blame/master/src/Electron.jl )

It seems the secure_cookie was added in the following PR and originally was secure because it was communicated to the child process via stdin rather than a command line argument:

https://github.com/davidanthoff/Electron.jl/pull/14

Unfortunately, this broke things on windows due to the bizarre WIN32 dicotomy between “console” and “GUI” executables. Therefore command line arguments were used:

https://github.com/davidanthoff/Electron.jl/pull/17

1 Like
3

Impressive detective skills! I’m pretty sure I tried looking at the git blame, but I wasn’t able to piece the story together as clearly as you did.

So to wrap it up, it seems the story here is that the secure cookie was originally intended to be passed via Electron’s stdin (hence securely), but then that doesn’t work on Windows and so the cookie was moved to the command line as a quick fix to make things work again.

1 Like
4

That’s right, and the quick fix turned into a not-so-quick fix :slight_smile:

Realistically though I’m not sure there’s actually a security hole here: It seems Electron only uses local sockets (unix domain sockets / windows named pipes), so an attacking process probably needs to be running as the current user (see Named Pipe Security and Access Rights - Win32 apps | Microsoft Docs for windows. For unix it depends on the permissions of the socket file which is created.).

If you’ve got an untrusted process running as the current user, the game is pretty much over anyway!

1 Like