Back to Blog Home

CVE-2024-45489 Incident Report

Tag:Security Bulletin
Published:September 20, 2024 at 3:20 PM

Hursh here, CTO and Cofounder of The Browser Company. We want to let all Arc users know that a security vulnerability existed in Arc prior to 8/25/24. We were made aware of a vulnerability on 8/25, it was fixed on 8/26. This issue allowed the possibility of remote code execution on users’ computers. We've patched the vulnerability immediately, already rolled out the fix, and verified that no one outside of the security researcher who discovered the bug has exploited it. This means no members were affected by this vulnerability, and you do not need to take any action to be protected.

Despite the low impact, this is the first serious security incident in Arc's lifetime. We’re taking this moment to upgrade everything from our internal security reviews, to our bug bounty program, to our communications with Arc members on such incidents.

Thanks to xyz3va for their private report and subsequent public writeup. Internal investigations are ongoing, but in the meantime want to share the technical details of the vulnerability.

What happened?

Arc has a feature called Boosts that allows you to customize any website with custom CSS and Javascript. Since running arbitrary Javascript on websites has potential security concerns, we opted not to make Boosts with custom Javascript shareable across members, but we still synced them to our server so that your own Boosts are available across devices.

We use Firebase as the backend for certain Arc features (more on this below), and use it to persist Boosts for both sharing and syncing across devices. Unfortunately our Firebase ACLs (Access Control Lists, the way Firebase secures endpoints) were misconfigured, which allowed users Firebase requests to change the creatorID of a Boost after it had been created. This allowed any Boost to be assigned to any user (provided you had their userID), and thus activate it for them, leading to custom CSS or JS running on the website the boost was active on.

Who was affected?

No Arc members were affected by this vulnerability. We did an analysis of our Firebase access logs and confirmed that no creatorIDs had been changed outside those changed by the security researcher.

Mitigation

xyz3va’s writeup goes into more detail about the steps to mitigate this vulnerability. On disclosure, we worked with them to patch our ACLs to fix this vulnerability, and confirmed the fix with them the following day. Considering the scale of the vulnerability, we also submitted for a CVE and, while we haven’t yet set up a formal bug bounty program, we worked to award a bounty for the issue.

Next steps

This was the first vulnerability of this scale that we’ve seen in Arc, and we really want to use this as an opportunity to improve how we respond to and disclose security vulnerabilities.

In terms of this specific issue, we are making a number of changes to avoid this moving forward and to improve our communication around security vulnerabilities:

  • We’ve fixed the issues with leaking your current website on navigation while you had the Boost editor open. We don’t log these requests anywhere, and if you didn’t have the Boosts editor open these requests were not made. Regardless this is against our privacy policy and should have never been in the product to begin with.
  • We’re disabling Javascript on synced Boosts by default. Any Boost with custom Javascript that was created on another device will need to be explicitly enabled moving forward.
  • We’re adding MDM configuration to disable Boosts for your entire organization.
  • We’re moving off Firebase for new features and products, mitigating future issues with ACLs.
  • We’re doing an emergency and more in-depth external audit of our existing Firebase ACLs to ensure there are no other vulnerabilities, in addition to our external security audits every six months. We are still planning to move off Firebase for all future features.
  • We’re establishing a security bulletin with clear comms around vulnerabilities, mitigations, and who was affected. We’ve been really inspired by Tailscale’s excellent security reporting, and we want to hold ourselves to the same standard.
  • We're establishing clearer guidelines for bounties, specifying which severity levels warrant particular reward amounts.
  • We’re adding security mitigations to our release notes. Since this was a server-side fix, it didn’t occur to us to include it in our client release notes, but since that’s the major venue where members get information about updates in Arc, they should be included there.
  • We’re also bolstering our security team, and have hired a new senior security engineer.

If you have any questions please reach out to us at [email protected]. As a team we will be using this moment to grow as a company and as engineers. We will integrate all of your questions, thoughts, and feedback into our larger discussions and full retrospective.