Researcher reveals ‘catastrophic’ security flaw in the Arc browser
Illustration: Cath Virginia / The Verge
A security researcher revealed a “catastrophic” vulnerability in the Arc browser that would have allowed attackers to insert arbitrary code into other users’ browser sessions with little than an easily findable user ID. The vulnerability was patched on August 26th and disclosed today in a blog post by security researcher xyz3va, as well as a statement from The Browser Company. The company says that its logs indicate no users were affected by the flaw.
The exploit, CVE-2024-45489, relied on a misconfiguration in The Browser Company’s implementation of Firebase, a “database-as-a-backend service,” for storage of user info, including Arc Boosts, a feature that lets users customize the appearance of websites they visit.
In its statement, The Browser Company writes:
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.
Or, in the words of xyz3va,
arc boosts can contain arbitrary javascript
arc boosts are stored in firestore
the arc browser gets which boosts to use via the creatorID field
we can arbitrarily change the creatorID field to any user id
You can get someone’s creatorID in several ways, including referral links, shared easels, and publicly shared Boosts. With that info, an attacker could have created a boost with arbitrary code in it and added it to the victim’s Arc account without any action on the victim’s part. That’s bad.
The Browser Company responded quickly — xyz3va reported the bug to cofounder Hursh Agrawal, demonstrated it within minutes, and was added to the company Slack within half an hour. The bug was patched the next day, and the company’s statement details a list of security improvements it says it’s implementing, including setting up a bug bounty program, moving off of Firebase, disabling custom Javascript on synced Boosts, and hiring additional security staff.
Illustration: Cath Virginia / The Verge
A security researcher revealed a “catastrophic” vulnerability in the Arc browser that would have allowed attackers to insert arbitrary code into other users’ browser sessions with little than an easily findable user ID. The vulnerability was patched on August 26th and disclosed today in a blog post by security researcher xyz3va, as well as a statement from The Browser Company. The company says that its logs indicate no users were affected by the flaw.
The exploit, CVE-2024-45489, relied on a misconfiguration in The Browser Company’s implementation of Firebase, a “database-as-a-backend service,” for storage of user info, including Arc Boosts, a feature that lets users customize the appearance of websites they visit.
In its statement, The Browser Company writes:
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.
Or, in the words of xyz3va,
arc boosts can contain arbitrary javascript
arc boosts are stored in firestore
the arc browser gets which boosts to use via the creatorID field
we can arbitrarily change the creatorID field to any user id
You can get someone’s creatorID in several ways, including referral links, shared easels, and publicly shared Boosts. With that info, an attacker could have created a boost with arbitrary code in it and added it to the victim’s Arc account without any action on the victim’s part. That’s bad.
The Browser Company responded quickly — xyz3va reported the bug to cofounder Hursh Agrawal, demonstrated it within minutes, and was added to the company Slack within half an hour. The bug was patched the next day, and the company’s statement details a list of security improvements it says it’s implementing, including setting up a bug bounty program, moving off of Firebase, disabling custom Javascript on synced Boosts, and hiring additional security staff.