Many of us use the Electron based VS Code as our Go editor (including me). Vulnerabilities like this make we wonder: Is it safe to rely on an unsafe browser as the the core of a major tool?
What do you think?
1 Like
All software has the potential for security vulnerabilities. Browsers, in recent years, have been incentivized to make the experience as secure as possible. Even the browsers you think are “safe” are still at-risk for security vulnerabilities, so it’s kind of moot. I think it’s safe to rely on technology that’s supported by a team that quickly responds to security issues:
We’d also like to thank the Electron team for being extremely responsive and for quickly providing a patch to the public.
The idea of cross-site scripting in my editor is far from ideal, but if you run another editor where they provide plugins are you auditing all of them to ensure there’s no malware there? I think the risk is similar in those situations.
My bigger issue with these editors is the implicit resource consumption required by them, in comparison to non-electron alternatives.
2 Likes
This. I don’t think we typically browse the untrusted web using vs code, but we implicitly trust any plugin we install and they have full access to the system.
1 Like
No, although this would be a good idea. All software that does not run in a sandbox and that can access the host OS can do harm. And every plugin for such software can do harm, too.
The problem of applications based on Electron seem to be that they rely on an embedded browser that can have all kinds of vulnerabilities. These vulnerabilities don’t seem to apply to applications that use other means to build their UI.
I admit I maybe didn’t fully understand the vulnerability and may be underplaying it, but my understanding is that it’s a problem if we’re looking at untrusted things in the Electron UI, as those untrusted things may be able to do more than we want them to. But the only things rendered in my VS Code UI are my code, things the plugins show, and the help/readme/etc for plugins in the installer interface. The latter two could be malicious, but that means the plugin is malicious and then we’re sort of back to square zero. I mean, the Go plugin for one grabs a dozen different programs from Github that it compiles and runs for me…
But I think this is a serious industry-wide problem. Any little javascript thing today pulls in literally thousands of modules in npm install, either one of which could be compromised, and some of them have been. Even a perfectly benign plugin might depend on some module that’s become evil in just the few hours before I install it and then I’ve lost, XSS or no. 
Qubes OS, anyone?
3 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.