Part of this is Electron's environment and arguably fault.

Electron used to default to insecure. You were basically running a web browser except with full access your entire machine file system/camera/mic/network etc. If you are an inexperienced developer it wasn't obvious that live linking to any 3rd party code could be an issue. Electron kind of fixed that. They warn you now and default to more secure. How many devs are capable of keeping it secure is up for debate.

As a related issue, it used to be (maybe still is) that by default, links you click in Electron open in Electron. So you make any app that accepts user data and links and suddenly people are browsing the entire net in an un-secured browser.

And worse, they break stuff. I made an electron app and explicitly made it so all links open in the user's browser. I updated to a new version and then to my horror found whatever I had done to make sure links opened in an external browser stopped opening links in an external browser.

Native apps can have exploits but most native apps aren't designed to be an environment for running arbitrary code. They're only an app for working on data.

Note, I love Electron, I've used it for several projects and it's great. But I'm also afraid of it and wish OSes were themselves more sandboxed so I didn't have to worry about it.

Nothing, but if Slack was a web application and not an Electron application it would mean XSS would not immediately lead to RCE, you would need XSS and a vulnerability in the browser to get an RCE. Electron is basically that for you already: a vulnerable browser.

I refuse to use the Slack desktop app, and use Slack only through a web browser. I trust Chrome (Google), Firefox (Mozilla), Safari (Apple) far more than the Slack engineers.

XSS isn't ordinarily RCE, and XSS is generally much more common than the attacks that do reliably give RCE. It's notable that un-hardened Electron elevates XSS to RCE, because it means there are a lot more opportunities for RCE. That's the subtext of the comment you're replying to.

Yes it is? XSS lets you execute javascript code remotely; that's literally a subset of RCE. Are you talking about virtual machine escapes (running native machine code)?

No, that is not remotely what practitioners mean by RCE.

"Remote Code Execution" means the attacker can Execute Code Remotely, right? I guess you could classify the virtual machine as a (virtually) separate machine from the physical one, so that it's not a RCE on the machine you actually want to attack, but it's clearly executing code on some machine that the remote attacker isn't supposed to be able to execute code on.

No. RCE is a term of art. It implies arbitrary native code execution.

> It implies arbitrary []native[] code execution.

This is simply not true in a plurality of cases (eg, it implies that applications running under qemu are incapable of having RCE vulnerabilities) and frankly sounds like a distinction that was made up to avoid admitting that script tags are RCE bugs in web browsers.

It's interesting how much this little subthread recapitulates the experience of responding to the median bug bounty submission.

Well, modulo "responding to a submission" versus "reporting a vulnerabity", we can certainly agree on that at least.

nodeIntegration:true