I'm really sorry about this, both the vuln itself and the delayed comms around it, and really appreciate all the feedback here – everything from disappointment to outrage to encouragement. It holds us accountable to do better, and makes sure we prioritize this moving forward. Thank you so much.
By the way, I don't know for sure, but given the severity I suspect on the black market this bug would have gone for a _lot_ more than $2k.
The case is redeemable. It may still be an opportunity if handled deftly. But it would require an almost theatrical display of generosity to the white hat (together, likely, with a re-constituting of the engineering team).
>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.
Given the context (boosts need to know the URL they apply to after all) this indeed was a "deliberate design choice" but not in the manner you appear to be suggesting. It's still very worrisome, I agree.
I think this should be a resigning matter for the CTO.
Pro tip: if stuff like this violently upsets you, never be an early adopter of anything. Wait 5-10 years and then make your move.
Personally, I expect stuff like this from challenger alternatives, this is the way it should be. There is no such thing as a new, bug-free software product. Software gets good by gaining adoption and going through battle testing, it’s never the other way around like some big company worker would imagine.
But it's also likely part of the startup mentally of "move fast and break things", which is not entirely compatible with the goal of the browser.
You've been handed a golden opportunity to set the right course.
The Browser Company raises $50mm at a $550mm post-money valuation in March [1]. They’ve raised $125mm altogether.
Unless they’re absolute asshats, they’ll increase the bug payout. But people act truly when they don’t think they’re being watched—a vulnerability of this magnitude was worth $2k to this company. That’s…eyebrow raising.
[1] https://techcrunch.com/2024/03/21/the-browser-company-raises...
Firebase is not to blame here. It's a solid technology which just has to be used properly. Google highlights the fact that setting up ACLs is critical and provides examples on how to set them up correctly.
If none of the developers who were integrating the product into Arc bothered about dealing with the ACLs, then they are either noobs or simply didn't care about security.
Firebase ACLs are a constant source of vulnerabilities largely because they are confusing and don't have enough documentation around them.
Is there a reason why you don’t have any security-specific positions open on your careers site?
Also, there's the whole notion of every URL you visit being sent to Firebase -- were these logged? Awful for a browser.
What is also unacceptable is to pay 2000 dollars for something like this AND have to create user accounts to use your browser. Will definitely stay away from it.
To explore a constructive angle both for the industry generally and the Browser Company specifically: hire this clever hacker who pwned your shit in a well-remunerated and high-profile way.
The Browser Company is trying to break tradition with a lot of obsolete Web norms, how about paying bullshit bounties under pressure rather than posting the underground experts to guard the henhouse.
If the Browser Company started a small but aggressive internal red team on the biohazard that is the modern web?
I’ll learn some new keyboard shortcuts and I bet a lot of people will.
Bringing the chaos back like it's 1999.
To be honest, I'm a bit disappointed. For future reference, this doesn't seem like a good strategy to contain reputational damage.
Maybe not. If the browser is that buggy, there may be plenty of these lying around. The company itself is pricing the vulnerability at $2k. That should speak volumes to their internal view of their product.
While people might nitpick on how things were handled, the fact that you checked if anyone was affected and fixed it promptly is a good thing.
Being prompt on a vulnerability of this magnitude should be considered "meeting the standard" at best.
The real issue here is that someone wrote an api that trusted the client to tell it who they were. At the end of the day this is an amateur mistake that likely took a 1 line diff to fix. Don't believe me? Check out the docs: https://firebase.google.com/docs/rules/rules-and-auth#cloud-... - `request.auth` gives you the user id you need (`request.auth.uid`).
Security rules are meant to be taken seriously, and it's your only line of defense.
Unfortunately, we currently have an industry where highly paid "engineers" unironically believe that their job can be done by reading/watching random tutorials, googling for StackOverflow answers, and pasting code from gists.
Attentively reading documentation or developing a mental model of how your tools work so that you know how they are built to be handled does not make it on to any job listing bullet points. It presumably fell off the bottom in favor of team spirit or brand enthusiasm or whatever.
How many tutorials, community answers, and gists do you think conveyed that warning?
I'm sorry but if the whole design is "one big database shared with everyone and we must manually configure the database for auth" there is a problem that's deeper than just having to read the doc. It means the basic understanding of what it means to keep data as private as possible is not understood. A shared database only works when the server accesses it, not when client has direct access.
What Arc needs is to segregate each user's data in a different place, in the design of the database, not as part of configuration of custom code. Make it impossible to list all user's data, or even users. When, not if, an id is guessed, related data becomes accessible by someone else; make it so that someone else still can't read it, or can't replace it.
It doesn't matter if you roll your own auth or not, you need to understand a very basic fundamental of it all: never trust the client.
God I wish. More than one of my coworkers has made this exact mistake with our (thankfully internal) front-end apps.
```
// Allow create new object if user is authenticated
allow create: if request.auth != null;
// Allow update or delete document if user is owner of document
allow update, delete: if request.auth.uid == resource.data.ownerUID
```
allow read, update, delete: if request.auth != null && request.auth.uid == userId;Leetcode is a fucking joke to the industry, gone are the days when you actually had good code with devs who spent time thinking about information architecture. In my experience boomer devs are actually the only ones who write idiomatic code. Millennial and Gen-z devs are the worst, they have no understanding beyond basic function calling.
const isReducedMotion =
window.matchMedia(`(prefers-reduced-motion: reduce)`) === true ||
window.matchMedia(`(prefers-reduced-motion: reduce)`).matches === true;
if (isReducedMotion) return;
about:config
ui.prefersReducedMotion = 0
sudo apt install oneko
oneko &
Current version is hard to even see with high-res screens. A few checks shows endless ports, code from the 90s and before, and all sorts of other fun.
Wonder if the author will reply.
Sometimes things like this handle connection failures better than "never-ending connection attempts", so you might want to try to add a throttle or something too for the traffic between the domain and the browser, might also trip it up.
I mean, even Google suggests doing this with sensitive data.
I guess now we know why they frame it that way.
So the OP is right. Arc's privacy is worse than Chrome.
On the other hand, with security rules you are trying to imagine every possible misuse of the system regardless of what its programmed use actually is.
Tbh you're doing it wrong if you go that way.
Default deny, and then you only have to imagine the legitimate uses.
The correct solution is likely default-deny auth for every single field. Then you at least have to explicitly make the owner field writable, and hopefully consider the impact of transfering this object to another user.
I don't work at FAANG. I just work at some company that makes crap products you don't actually need, and even I would never build this kind of bug.
But these people want to build a web browser, with all the security expertise and moral duty that implies?! Wow.
Honestly I strongly feel the title should be “fundamental bug in Arc browser (CVE 123-4567)” or similar.
This is not one of them. In my opinion, this shows a kind of reputation-ruining incompetency that would convince me to never use Arc ever again.
aug 25 5:48pm: got initial contact over signal (encrypted) with arc co-founder hursh
aug 25 6:02pm: vulnerability poc executed on hursh's arc account
aug 25 6:13pm: added to slack channel after details disclosed over encrypted format
aug 26 9:41pm: vulnerability patched, bounty awarded
sep 6 7:49pm: cve assigned (CVE-2024-45489)
EDIT: Oh, the date changed; so it was 28 hours until fix. Still decent; and half an hour from initial contact to "Join our slack channel" is incredibly fast response time.
In other words, a quick turnaround with a fix does not lessen the impact of being negligent about security when designing the product.
Phew, glad that's over and will never happen again.
50-60mm cash at 500mm (!) valuation and no business model is a big red flag when it comes to something as important, as personal as a browser. This is not a charity. Someone, somehow will have to pay for that.
Except… the growth hacks have started to creep in. They overlay an advert for their own AI services on top of regular Google search results pages in their mobile app. Not even a browser chrome UI element, it’s literally over the page content. That feels like a huge violation of what it means to be a browser.
I don’t want their AI features. I don’t want growth hacks. I don’t want to sign in except for sync. I’d happily pay $40 a year for Arc as a product-focused-product, but as a VC-focused-product it’s heading downhill.
Also, shame on firebase for not making this a bit more idiot proof.
And really? $2500? That’s it? You could’ve owned literally every user of Arc… The NSA would’ve paid a couple more zeros on that.
only the 17 users they have.
Shouldn't a government sue you if you try to sell him out vuln unless you personally know people in charge?
I was already aware of it when being a noob dev 10 years ago, and could easily write a rule to enforce auth + ownership in the rules. No way, seasoned devs can miss that.
(just imagine , this author was great for telling the company , this is also a cross platform exploit with very serious issues (I think arc is available on ios as well))
how many of such huge vulnerabilities exist but we just don't know about it , because the author hasn't disclosed it to the public or vulnerable party but rather nsa or some govt. agency
How does The Browser Company make money? They're giving their product away for free.
Browsers are complicated. It doesn't inspire confidence that the folks in charge of that complexity can't get their heads around a business model.
(Aside: none of their stated company values have anything to do with the product or engineering [1]. They're all about how people feel.)
TL;DR: it's not possible to export data from Arc, but it's possible to copy-paste the folder to a Chrome profile, and Firefox and other browsers will detect&import it.
Browsers are very important part of our life. If someone compromises our browsers , they basically compromise every single aspect of privacy and can lead to insane scams.
And because arc browser is new , they wanted to build fast and so they used tools like firebase / firestore to be capable of moving faster (they are a startup)
Now I have read the article but I am still not sure how much of this can be contributed to firebase or arc
On the following page from same author (I think) https://env.fail/posts/firewreck-1 , tldr states
- Firebase allows for easy misconfiguration of security rules with zero warnings
- This has resulted in hundreds of sites exposing a total of ~125 Million user records, including plaintext passwords & sensitive billing information
So because firebase advocates itself to the developers as being safe yet not being safe , I think arc succumbed to it.
firestore has a tendency to not abide by the system proxy settings in the Swift SDK for firebase, so going off my hunch,
Also , you say that you have been convinced to never use arc again.
Did you know that chrome gives an unfair advantage to its user sites by giving system information (core usage etc.) and some other things which are not supposed to be seen by browsers only to the websites starting with *.google.com ?
this is just recently discovered , just imagine if something more serious is also just waiting in the shadows Couldn't this also be considered a major security vulnerability just waiting to be happen if some other exploit like this can be discovered / google.com is leaked and now your cpu information and way more other stuff which browsers shouldn't know is with a malicious threat actor ?
And browser development is exactly not the area where I would like to see the "move fast, break things" attitude. While firebase may be sloppy with security and thus unfit for certain purposes, I would expect competent developers of a browser to do due diligence before considering to use it, or whatever else, for anything even remotely related to security. Or, if they want to experiment, I'd rather that be opt-in, and come with a big banner: "This is experimental software. DO NOT attempt to access your bank account, or your real email account, or your social media accounts".
With that, I don't see much exploit potential in learning stats like the number of cores on your machine. Maybe slightly more chances of fingerprinting, but nothing comparable to the leak through improper usage of firebase.
That's pretty interesting. Where can I learn more about this?
Yeah so using chrome based browsers like Arc is giving more power to Google to do shady stuff while also being a victim of the third party unsafe code.
The fact that they don't even mentioned this bug/fix on any of their social media is quite alarming.
I enjoyed my time with Arc, but I can't possibly see myself continuing to use it after the way they handled this.
As many other comments have pointed out, this vulnerability is such a rookie mistake that I don't think I can trust them again after this without understanding what factors in their security/engineering culture led to it. Patching this one issue isn't enough.
Are you not concerned with the yet to be discovered vulnerabilities?
What is concerning is the nature of the vulnerability and how it speaks to their security culture (which is obviously non-existent). This also revealed that their privacy policy is pure marketing fluff, completely disconnected from (and, in fact, counter to) their actions.
If you are comfortable using a browser (probably the software with the largest risk and attack surface on your device) that had an embarrassingly rudimentary vulnerability, made by a company who lie about the most important promise of their privacy policy, then I've got a calculator app for you.
I would go the other way, companies offer low bug bounties because they don't want researchers to discover them in the first place. This looks terrible for Arc despite the fact if left undisclosed it probably would have continued to be unexploited for years to come.
Why? I really couldn't say. I think we just like the feel of it. The only reason I type with proper capitalization on HN and my blog is because I know older people read it.
/s
[1] https://resources.arc.net/hc/en-us/articles/19212718608151-B...
And what about all the other that have not been reported or may be exploited ?
From now on, every time someone is going to suggest arc browser, there will be another one to remind everyone of that. That's going to be very difficult to overcome when your software already doesn't have that big of a market share.
And who's going to take the bet that they'll find nothing? Not me.
Is this the rule that was missing for arcs boosts or whatever object?
```
match /objects/{object} {
// Allow create new object if user is authenticated
allow create: if request.auth != null;
// Allow update or delete document if user is owner of document
allow update, delete: if request.auth.uid == resource.data.ownerUID
}
Also, for anyone trying to read the article, they should put `/oneko.js` in their adblocker.
Only if you hate cats, pixel art, or are easily distracted.
I'm not very familiar with Firebase. In what way is it broken and what issues does it cause?
I'm definitely not the target audience... Even after reading the faq I have no idea what it does
Doesn't matter if you build the most secure product if nobody is using it, right? Where that breaks down is that a browser MUST be relatively secure, otherwise you've given up the whole ballgame.
A glance at Arc's privacy policy makes it clear they aren't privacy anything [1]. (Contrast their device and product usage data sections with Kagi's [2].)
[1] https://arc.net/privacy#what-personal-data-do-we-collect-and...
[2] https://help.kagi.com/orion/privacy-and-security/respecting-...
now, when talking about ARC BROWSER, i am seriously starting to doubt the competence of the team. I mean, if the rules are broken (no tests? no rules whatsoever?), what else is broken with ARC? are we to await a data leak from ARC?
any browser recommendations with proper vertical tabs and basically everything working like it does in ARC?
Vivaldi may also be worth a look. Similar setup: User-oriented team, vertical tabs, e2ee sync. If you like a thorough browser history, I think Vivaldi keeps a more detailed browsing history than most other Chromium browsers.
I'm not surprised in the least --- basically the vast majority of software these days is spyware. Looking at Arc's privacy page, it appears to be mainly marketing fluff similar to what I've seen from other companies. I have yet to find a privacy policy that says frankly "we only know your IP and time you downloaded the software, for the few weeks before the server logs are overwritten."
I'd rather a company have simple goals that can be explained in a sentence or two. No hand wavey BS like "we care about your privacy"
Not with those exact words, but that’s Alfred. Server connections are done only to validate the license and check for updates, and you can even disable that.
https://www.alfredapp.com/terms/
> Alfred only contacts our server when activating your Powerpack license in order to validate it, as well as periodically checking for new software updates. You can disable the software update check in the Update preferences, but we recommend keeping this enabled to ensure that you always have the latest version for security reasons and to make the most of the awesome new features!
> i discovered that there was a arc featured called easels, easels
> are a whiteboard like interface, and you can share them with people,
> and they can view them on the web. when i clicked the share button
> however, there was no requests in my mitmproxy instance, so whats
> happening here?
I thought this was novel, and assumed it was just something to do with websockets, so I switched to another, non-firebase-but-yes-websockets project and noticed it didn't work.
At the time, I debated moving calls to Firebase just so that I could work for free while I was on flights, but realized the ROI wasn't remotely there. Glad to finally have someone else acknowledge it happening, and give some insight as to why.
BTW, on Arc's website on "Security" there still is no mention of this vulnerability (as of 20th Sep 2024, 2:32 pm PT)
Check it out - https://arc.net/security
Apparently the company had contracted with one Latacora for "regular outside security reviews and trainings across a wide range of different systems".
Elsewhere on the page, it says "Arc uses GCP Firebase for user authentication, storage for Notes & Easels, and Cloud Functions for certain application features like referral code generation. All data stored in Firebase is encrypted-at-rest by default."
But it’s so much easier for developers to think of userid as just another parameter, and they forget, and oops now they trust a random user-supplied parameter.
After seeing this level of incompetence, I am happy they didn't attempt that.
Yet.
That's pretty bad, whether or not they track these requests, just seems wasteful.
Also the forum shills are worse than Brave ones.
also it's so incredibly easy to really fuck up and build something exploitable.
are javascript devs really that afraid of doing things themselves to this extreme level?
> are javascript devs really that afraid
You might be afraid of JS devs :P Anyway has nothing to do with language, even if it was a super c0ol Ruby-on-Rails app with Active Record and SQL db on a server you manage it's still common to have some stuff in NoSQL for fast access to live data, caches, logs, etc. Most companies at scale will have both SQL and NoSQL dbs in areas. So if you're already using S3 for files, code on GitHub, storing keys in 1Pass, why not use a Firebase or MongoDB for high traffic live data? Especially if they offer built-in scaling and geo deploy options.
This scenario I laid out is kinda to your point of "don't anchor your entire company on it" - the only point I'm trying to add is that you can also use these tools without the company being "anchored" on it, and they could have still ran into the same issue as Arc.
+ The ability to enforce automatic updates + Ability to control which sites extensions/boots are installed on
On top of this there seems to be no way to remove the requirement to have an account to use the browser, selectively choose what data is sent/sync'd from Arc, or disable basic features like Easel through which staff accidentally leak data.
The UI for the browser is great, but Arc really needs to lay the groundwork for strong security controls or it'll struggle to gain (or even maintain) a foothold in the enterprise space.
As someone who has done some reverse engineering of macOS apps but haven't used anything beyond Charles' macOS proxy feature, this looks very painful. Is there a proxy app that maybe acts as a VPN so that basically every HTTP request is guaranteed to go through it, so that you don't need to write a hundred lines of bespoke Frida just to capture requests?
Edit: On second thought Proxifier should work for this purpose.
I assume you'll have to install a root cert in order to introspect HTTPS traffic though.
Unfortunately it’s at the root of almost all of my career’s worst bugs and mistakes (not necessarily caused by me), and it seems like a bit of train wreck in the wrong hands. I’ve had to rescue several clients from it, and have migrated three pretty huge applications off of it now.
I’m not sure what it is exactly. People really abuse the hell out of it.
EDIT: seems to be a browser or so?
The devs that wrote these rules had to intentionally allow overly broad reads/writes to this part of their database in order to create this vulnerability. And this had to pass code review and automated testing.
That’s not good, and it has nothing to do with their choice of tools.
Props to her, she asked about the security and privacy of the browser and I played it off with some fanboy propaganda. Lesson learned on that one. If I only care about the vertical tabs, workspaces, and a (decent) mobile app are there any good equivalents right now?
I use Firefox mostly because of Sideberry (which does vertical tree-style tabs) which also integrates with "containers", so you can have something similar to workspaces but more isolation. Otherwise there is also "profiles" that probably offer even more isolation between the different profiles.
It works, it's boring, and it doesn't try to shove gimmicky features in my face.
But experience is probably different.
Browsers are hard and my only choice has been chrome and will remain so for the long foreseeable future.
When I was younger I would enjoy switching to firefox, opera, etc..
But I always came back to chrome because it just worked and always performed when I needed.
Chrome/chromium is the safest browser.
People tend to fall for the shiny new thing and then realize it was just hype.
Please be very careful about what software you choose to perform most of your activities.
The same applies to these “new ai IDEs” that keep popping up every other say.
I used Chrome for years and years, right from when it first came out. Since then, I switched back to Firefox, and have used it for years. It works perfectly fine.
People often confuse these two, but they’re the polar opposites.
Interestingly enough, contains a field for entering your Father's name (but not your mother's).
I tried Arc a while ago but switched back to Chrome. Quite glad I did now.
> firebase .collection("boosts") .where("creatorID", "==", "UvMIUnuxJ2h0E47fmZPpHLisHn12") .where("hostPattern", "==", "www.google.com");
> the hostPattern being the site you visit, this is against arc's privacy policy which clearly states arc does not know which sites you visit.
This does not seem like a browser capability I want.
We don’t know which websites you visit
People say they like arc for the UI and there are all alternatives, but do you really want to risk someone stealing your bank creds and stealing all your money for some fancy UI?
> Total Funding Amount $68M
the browser company normally does not do bug bounties, but for this catastrophic of a vuln, they decided to award me with $2,000 USD
I'm struggling to put into words how disappointing I find this.
I do wish that more companies would take privacy and security seriously. And bug bounty programs are great. But they're not always within the budget of companies and the fact that they decided to award this security researcher regardless of having no such program is a massive win in my opinion and shows how much they value this particular contribution.
Blog authors: stop assuming I know about the existence of every piece of software.
(also maybe occasionally consider using the Shift key on your keyboard so you can capitalise things :)
Someone recently recommended Arc to me, I installed it on my macbook and then never actually used it when I realized there's no Linux version available, and I like a consistent browser experience across all my devices.