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!
9:21 PM on July 16, 2020 we received a very detailed report from Masato outlining this exploit.
9:34 PM: Ticket acknowledged - and we began a deploy that would disable sketchfab embeds within the app, to remediate this known attack vector.
10:00 PM: Update pushed to stable to disable all existing sketchfab embeds.
Thanks to the detailed report, we were able to go from a report to a fix deployed to stable in ~40 minutes!
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.
----
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 not as simple as flipping a boolean from false -> 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 & 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.
In August, we shipped context isolation to our Stable release channel and gave Masato the green light for disclosure - which leads us to today!
It's cool you guy fixed it so fast and deserve some good PR here for that but I'm surprised you paid out $5k for an RCE. That's unspeakably cheap for something that could have fucked over many of your users.
I work at a very small company, so small that a security researcher would never accidentally stumble on our products to test them and if my boss asked me what would be an appropriate pay out for this, I'd say easily $25k, but more likely 30-35k if we can afford it.
What you guys have accomplished here is set a precedence that you pay so little that researchers should either a) not bother with discord or b) should sell on the darknet.
As a discord app user, I'm very concerned about both of those cases.
The issue is that the bug was technically in a 3rd-party dependency:
> even though the main fault that lead to RCE was due to a bug in Electron (CVE-2020-15174)
This may seem like an irrelevant detail if you’ve never operated a bug bounty program before, but you have to consider the incentives.
Paying researchers for bugs in 3rd-party open source software creates misaligned incentives. If you’re a security researcher and you discover a security bug in Electron, you have two choices:
1) Follow proper protocol to create a CVE, coordinate a fix, and properly disclose the issue through appropriate channels.
2) Keep the vulnerability secret and unfixed while you shop it around bug bounty programs looking for kind companies who will pay out for 3rd-party issues. To maximize profits, it’s important that you keep the security issue unfixed and secret as long as possible while you work your way across bug bounty programs.
The second option is a little publicized negative externality of bug bounty programs that don’t draw the line at 3rd-party dependencies. I’ve even had bug bounty participants beg us to not fix upstream code yet because they were still trying to collect bounties from other companies.
This is also why it’s important to have your security team read every CVE immediately and check against your software. It’s also why bug bounty programs don’t pay out as much, or even at all, for security issues that come from popular 3rd-party dependencies used across the industry.
I appreciate your insight into the 3rd party aspect of BB programs but I fear you're also setting a dangerous precedant of _outsourcing liability_ from major companies to small open source devs.
If I get hacked and find out Discord was the vector, I'm not going to let them off the hook when they shrug and say "3rd party code man, it happens". In the end, I'm a discord user, I don't want RCE exploits in software I use.
If the bug was instead reported to Electron and given a CVE, Discord could have still implemented the fix. Either a workaround in their app or an upstream patch.
Given that discord chose electron as a dependency it's at least partially their responsibility. They are putting their users at risk for choosing that dependency.
Thanks for the insight, I can imagine it was quite an impressive refactoring effort!
> 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
You seem to imply that because the bug was in a library that you use as opposed to code your own developers wrote, that it's gracious of you to even pay out $5000 for this bounty. Surely that's not actually what you're saying and I'm merely misunderstanding you? Regardless of who wrote the bug, Discord ships the binary and the impact of the vulnerability remains the same.
I'm sensing a trend in the replies here, which is that this was too low a pay out, perhaps we should have a discussion about what is a worthy payout, because we based this off of what we saw other companies paying out.
Our bug bounty page on H1 (invite only currently) lists critical vulnerabilities at $3,000 for a bounty, we decided to up the pay-out to $5,000 for the thorough report on the exploit - even though the vulnerability was not in our code, we paid extra (from our perspective...) because the vulnerability did after all ship in our software.
I compared this to similar payouts for RCE's, for example, slack paid out $1750 for a similar RCE earlier this year, due to lack of context isolation (https://hackerone.com/reports/783877) - although this did get published after we paid bounty - so it did not influence our decision.
Clearly there is some discussion to be had about what is fair. For context (which might be missing), this was not a 0-click drive-by RCE, and to exploit involved 4-clicks you had to be sent the embed, (1) click the "play" button to launch the iframe [we never load iframes with 0click], (2) click play within sketch-fab to load the 3d model, (3) click a small "1", and then (4) click a "+" in the tooltip that pops up in order to trigger the exploit. I'm curious if anyone has prior art or opinions on what would be a more appropriate bounty?
The reason I'd personally say it's unfair is because Discord should do their own fair calculations, not just copy what another low-paying company pay may have given before.
Discord is valued at several billion dollars, and their last funding round was over a hundred million. They are a key component in the lives of at least a hundred million people. Given this, $5,000 is, in my opinion, negligible, and the proper payout would have been at least double.
Given that Discord permanently stores so many chat logs, personal information, analytics, etc, there should be no higher priority than maximizing security and user trust, and $5K would make me, as a potential user, think it's a second priority.
The questions you need to ask are what is the cost of the alternative?
What is the cost in the exploit being used in the wild?
What is the cost of the PR shitstorm that would come your way?
How much business could you lose? Customer confidence?
Is this an exploit that could be devastating to your continued operations? Would it lead to legal action? What are your duties to inform customers/users/legal bodies? Will there be any fines involved? You may need to retain an expert PR firm to handle the communication to the world to put a good spin on the story, another cost. Did you breach GDPR? Does the data that could have been leaked reveal business practices you'd rather keep secret? Is there any kind of internal risk of leakage? How far does the exploit go? Can it be combined with other exploits that could be used to gain access to internal systems?
The industry has collectively decided that exploits have a value and I'm not sure these factors are taken into account. You should look at examples of companies that have suffered an attack and look the damaged caused (for example, Experian, Blackbaud come to mind) to understand the impact it can have.
How much does it cost to have a CEO tweet the stock price is "too high imo" and causes a dip? That may cost him potential investors to think again.
Of course, you can't know that person who was just about to give you $50,000 worth of business decided not to because of how you handled the situation but it's always a possibility.
I know I've made (small) decisions like this because I didn't like how it was handled or didn't agree with some of the details, and I no longer consider myself a possible customer as a result.
Thanks for the explanation. Would you say security issues are the main reasons you update? I open Discord once or twice a week and I feel like there's always an update or 3 waiting.
9:21 PM on July 16, 2020 we received a very detailed report from Masato outlining this exploit.
9:34 PM: Ticket acknowledged - and we began a deploy that would disable sketchfab embeds within the app, to remediate this known attack vector.
10:00 PM: Update pushed to stable to disable all existing sketchfab embeds.
Thanks to the detailed report, we were able to go from a report to a fix deployed to stable in ~40 minutes!
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.
----
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 not as simple as flipping a boolean from false -> 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 & 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.
In August, we shipped context isolation to our Stable release channel and gave Masato the green light for disclosure - which leads us to today!