Discord Desktop App RCE

Hi all! Discord Employee here that was involved in the remediation of this exploit! I just wanted to clarify with a timeline, and explanation as to why we had context isolation disabled!<p>9:21 PM on July 16, 2020 we received a very detailed report from Masato outlining this exploit.<p>9:34 PM: Ticket acknowledged - and we began a deploy that would disable sketchfab embeds within the app, to remediate this known attack vector.<p>10:00 PM: Update pushed to stable to disable all existing sketchfab embeds.<p>Thanks to the detailed report, we were able to go from a report to a fix deployed to stable in ~40 minutes!<p>Following that, the next day we deployed a better update as we understood more about the issue (which was the sandbox attribute on the iframe.) In addition, we also paid out $5,000 for this bounty, even though the main fault that lead to RCE was due to a bug in Electron (CVE-2020-15174) which allowed for a bypass of our CSP, by allowing the main window to be navigated to a different domain.<p>----<p>As for context isolation, a lot of the code that had been written was not compatible with contextIsolation - and required significant work to refactor. For example, due to the way that objects needed to be cloned to pass through the bridge, the internal APIs that existed needed to be entirely reworked, as they were not really compatible with this model. We began this work in April shortly after we worked out all the quirks required to upgrade to Electron 7 which is when contextBridge would be available for us to turn on contextIsolation. It was <i>not</i> as simple as flipping a boolean from false -&gt; true, and required a re-work of our native modules and their internal APIs, and also doing so in a way that would be backwards &amp; forwards compatible with the various app versions that we had shipped in the wild - in addition to dealing with some performance regressions that needed work-arounds in the new context isolated world.<p>In August, we shipped context isolation to our Stable release channel and gave Masato the green light for disclosure - which leads us to today!

My main takeaway from this article is the question why conextIsolation was introduced defaulting to false.<p>This is one huge lever to help with the maxime “XSS is RCE in electron” and yet they default to not helping.<p>I know this is about backwards compatibility, but they could easily have decided to throw if the property is unset. Security-minded people would have set it to true and dealt with the fallout, whereas others could have set it to false and shipped their update still.<p>But by defaulting to false, this security tool is hidden from both existing and new users. Old code will not even have the chance to get fixed and new code will be written in an insecure state.<p>I’m sure the release notes talked about this feature, but who reads release notes? Especially not past release notes (when starting fresh today).<p>The backwards compatibility cost of throwing and in the message even suggesting setting to false as an emergency out would have been minimal compared to the fallout this is causing.

These types of exploits are exactly why I just prefer to use the browser version of everything. The browser is superior (both mobile and desktop). It’s safer, typically faster and less resource intensive, and it has reliable and consistent controls. For example, “going back” means something different to every app, but in safari it’s always just a click away.<p>And most importantly in the browser I can have full ad blocking&#x2F;tracking protections enabled.

Needless self-promotion; this is why I came up with this template, to build secure electron apps. It is obvious that current industry has not caught up with secure practices for Electron apps, and I hope this template can help people in their endeavors.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;reZach&#x2F;secure-electron-template" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;reZach&#x2F;secure-electron-template</a><p>*contextIsolation is turned on in this template, so the RCE as described in the article is prevented.

Discord <i>is</i> a remote control backdoor. It just isn&#x27;t an exploit because that&#x27;s how Discord is designed.<p>They send a tracking request for every single thing you do in their client. Clicked on someone&#x27;s profile, clicked on a channel, clicked on a server, etc. The URL was named &#x2F;track before but they renamed it to &quot;&#x2F;events&quot; and then recently &quot;&#x2F;science&quot; (but it&#x27;s still a POST with no response).<p>Also their desktop client is literally a remote administration toolkit, it has full access to FS (electron app) and it loads every script from their servers. On launch the desktop client opens websocket server for command and control listening.<p>They can just add something like require(&#x27;fs&#x27;).readFileSync(process.env.HOME + &#x27;&#x2F;.ssh&#x2F;id_rsa&#x27;).toString() and send this to their servers, and you won&#x27;t even notice that (since it doesn&#x27;t require an update on client because the client is just a browser with full permissions that loads obfuscated code from their servers every time you launch it).

This is both a pitiful amount of money for finding flaws in three different pieces of software but at the same time the biggest thing Discord did wrong was not practicing defense in depth through disabling contextIsolation.<p>Although it makes sense, I&#x27;m almost surprised Discord paid out given that biggest reason the RCE exists was due to the Electron top-level navigation bug allowing XSS despite Discord&#x27;s existing mitigations in the first place.

Every time I’ve looked at using Electron I’ve tried to figure out if it can be made secure from RCE in the face of XSS (which is inevitable).<p>Discord didn’t set contextIsolation to true. Why? No idea. Would it have been enough if they did? No idea.

Didn&#x27;t know Discord has the domain &quot;watchanimeattheoffice.com&quot;, lol.

Wow, only 5k for this? discord is cheap.

Electron is going to get a lot of shit for this, but this is really Discord&#x27;s screw-up for allowing third-party (e.g. not vetted) iframe embeds.. why would that ever be a good idea? CVE-2020-15174 is an interesting exploit (the only part I find pretty damning).

$5k for this? I hope they sell the next RCE to black hats, maybe that will teach Discord something.

Some orgs (edus and non-profits) only have 10k to 20k per year for their entire bug bounty program. So when setting the price of RCE, we should keep that in mind. Not all of us have tons of cash. Recognition and resume building is a huge value as well.

More details on CVE-2020-15174 Electron navigation restriction bypass here: <a href="https:&#x2F;&#x2F;www.cvebase.com&#x2F;cve&#x2F;2020&#x2F;15174" rel="nofollow">https:&#x2F;&#x2F;www.cvebase.com&#x2F;cve&#x2F;2020&#x2F;15174</a>

how many RCEs in ripcord, I wonder :-)

Just using &quot;sandbox&quot; attribute would fix it. Most of the time this is a reasonable situation and I try to remember to use it on 100% of iframing (until it breaks) - I hope you will too.

Time to uninstall Discord desktop and use the web version.

Are such exploits possible in electron, or is it sandboxed to prevent such errors?

It&#x27;s probably telling that I&#x27;m a) older and b) paranoid that my internal translation of RCE was &quot;Resume Creating Event&quot;; e.g. a screw-up so bad that a new resume was needed to be produced to begin a new job search.