Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gaining access to anyones Arc browser without them even visiting a website

kibty.town

Post reply on HN
Print view View original

501–510 of 538 posts

Re: Gaining access to anyones Arc browser without them even visiting a website

#501

Post by kfarr »

GVRV wrote: post #445
kfarr wrote: post #211

Earlier quoted context omitted.

Agreed, if I understand correctly the fix to this issue would be the following rules inside of a "match" statement in firestore.rules which is plainly documented as firebase firestore security 101: ``` // 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.owne…

Didn't they already have these rules in place? And the vulnerability was when the owner was updating the resource to have a new owner?

Unclear if they had these rules in place already but I'm curious... If the rule permits writing when the userid matches, presumably there is nothing stopping the write operation to change the userid value, to your point.

Which then leads me to the next question, what is the practical way to write rules against that operation?

Re: Gaining access to anyones Arc browser without them even visiting a website

#502

Post by sieabahlpark »

zamadatix wrote: post #499
zamadatix wrote: post #406

Earlier quoted context omitted.

Right now You and Arc are advertising it's ideal to position posts such as "Hidden Features in Arc Search" to users but security bulletins and remediations are something that need a hidden stopgap until you've scrambled to build an alternative site to hide them away at instead. Browser security is more than finding the best PR strategy, it's a mindset that prioritizes the user's well being over the product's image. I…

The sibling comment to this by sieabahlpark is already dead but to respond in case they get a chance to read the thread again anways: The engineers already closed the hole, the blog post was already published, more work was (/is still?) going to be done to make a new site to hide them in. I wasn't asking for them to move engineers off patching to blog posting, I was asking for the already created blog posting to be m…

Every comment I make is immediately dead upon me posting, it's been that way for about a year.

I believe transparency is necessary, but also have been in the situation where the alarms are going off and you slip on making sure disclosures are optimally distributed. Generally I'm just concerned that it's documented at all.

Now if they maintained not revealing the security issue over the following week I'd agree.

Should they have had a bulletin stating when it occurred in August? Absolutely. I'm not disagreeing, and the distance from that event I would agree with you. However, considering just how fundamental the security vulnerability was there isn't exactly an immediate benefit to blast that to the world. It opens up the spotlight for more advanced attacks to take advantage of other unpatched holes.

Taking the time to go through and _really_ make sure it's patched (as well as a general check around the codebase for other EZ vulns) is, in my opinion, the better option.

Now if this had been a larger timeframe and repeated offense I'd agree the security hygiene for Arc should be bumped up in priority ASAP and until that probably happens Arc as a platform could not be trusted.

Re: Gaining access to anyones Arc browser without them even visiting a website

#503

Post by esperent »

rakoo wrote: post #356
tr3ntg wrote: post #181

Earlier quoted context omitted.

As someone with an app built on firebase, yes. As the author rightly points out, it's very easy to misconfigure, but basic security practices like these are highlighted in bright, bold warning text in the Firebase docs. Security rules are meant to be taken seriously, and it's your only line of defense.

> it's very easy to misconfigure, but basic security practices like these are highlighted in bright, bold warning text in the Firebase docs. 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 possi…

Also how does this work legally with regards to data sovereignty? Is it just a case of hoping nobody notices/complains?

Re: Gaining access to anyones Arc browser without them even visiting a website

#504

Post by FleetAdmiralJa »

ha470 wrote: post #213

I’m Hursh, cofounder and CTO of The Browser Company (the company that makes Arc). Even though no users were affected and we patched it right away, the hypothetical depth of this vulnerability is unacceptable. We’ve written up some technical details and how we’ll improve in the future (including moving off Firebase and setting up a proper bug bounty program) here: https://arc.net/blog/CVE-2024-45489-incident-response…

I think the bigger question is: Why are you violating your own security policy by keeping track on what we browse. I though my browsing is private and hidden away from you but if you store my browsing data in your firebase this is not acceptable at all.

Re: Gaining access to anyones Arc browser without them even visiting a website

#505

Post by thruway516 »

pembrook wrote: post #344
tyho wrote: post #219

Earlier quoted context omitted.

There isn't really anything you can do to convince me that your team has the expertise to maintain a browser after this. It doesn't matter that you have fixed it, your team is clearly not capable of writing a secure browser, now or ever. I think this should be a resigning matter for the CTO.

Surprise surprise, turns out it takes a looong time for every software startup to finally strip out all the hacky stuff from their MVP days. Apparently nobody on this startup community forum has ever built a startup before. 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,…

I don't think you understood the severity or the noobiness of the error. This is a browser not a crud app or electron app. A browser is a complex system level piece of software not a hacky mvp and this kind of error shows that maybe they don't have the competence to be building something like this. It makes you wonder what other basic flaws are there just waiting to be exploited, even if its built on top of chromium. Would you fly in an mvp airplane built by bicycle engineers? (maybe not the best analogy since the first airplane was built by bicycle engineers)

Re: Gaining access to anyones Arc browser without them even visiting a website

#506

Post by pembrook »

thruway516 wrote: post #505
pembrook wrote: post #344

Earlier quoted context omitted.

Surprise surprise, turns out it takes a looong time for every software startup to finally strip out all the hacky stuff from their MVP days. Apparently nobody on this startup community forum has ever built a startup before. 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,…

I don't think you understood the severity or the noobiness of the error. This is a browser not a crud app or electron app. A browser is a complex system level piece of software not a hacky mvp and this kind of error shows that maybe they don't have the competence to be building something like this. It makes you wonder what other basic flaws are there just waiting to be exploited, even if its built on top of chromium.…

Agreed, I wouldn’t have hopped on the first airplane with some bicyclist named Wilbur. That would involve risk of immediate physical harm.

On the other hand, we’re talking about a 2 year old browser leaking what websites you visit. Do you also think Firefox in 2006 was bulletproof? The entire internet and every single OS & browser was a leaky bucket back then.

The current safety-ism, paranoia and risk-aversion around consumer software on this forum is hilarious to me. Maybe they shouldn’t have called this place “Hacker” news, because it’s now full of people LARPing as international intelligence agency targets from a 90s movie. If the prying Five Eyes are such a concern for you, maybe use a fake email when signing up for stuff and your browser history is instantly anonymized.

Yes, startups involve lots of risk (to everyone involved, users/employees/founders/investors). But risk is the only way we get new things. If you those risks are too scary for you, stay far away startups.

Re: Gaining access to anyones Arc browser without them even visiting a website

#507

Post by make3 »

NewJazz wrote: post #196
zachrip wrote: post #143

I just want to call out that there is a lot of blame put on firebase here in the comments but I think that's just people parroting stuff they don't actually know about (I don't use firebase, I have tried it out in the past though). This isn't some edge case or hard to solve thing in firebase, this is the easy stuff. The real issue here is that someone wrote an api that trusted the client to tell it who they were. At…

At the end of the day this is an amateur mistake God I wish. More than one of my coworkers has made this exact mistake with our (thankfully internal) front-end apps.

I guess we're not always professionals at all the work that we do, if that makes sense

Re: Gaining access to anyones Arc browser without them even visiting a website

#508

Post by zamadatix »

zamadatix wrote: post #499
zamadatix wrote: post #406

Earlier quoted context omitted.

Right now You and Arc are advertising it's ideal to position posts such as "Hidden Features in Arc Search" to users but security bulletins and remediations are something that need a hidden stopgap until you've scrambled to build an alternative site to hide them away at instead. Browser security is more than finding the best PR strategy, it's a mindset that prioritizes the user's well being over the product's image. I…

The sibling comment to this by sieabahlpark is already dead but to respond in case they get a chance to read the thread again anways: The engineers already closed the hole, the blog post was already published, more work was (/is still?) going to be done to make a new site to hide them in. I wasn't asking for them to move engineers off patching to blog posting, I was asking for the already created blog posting to be m…

(repeat of the above response type. Sorry if this breaks a rule or something Dang, but it's a pretty tame/decent conversation)

This is still responding to a different complaint. The operational performance of "optimally distributing" the message, or however you want to word it, on was/is both imperfect and perfectly fine at the same time. Where the ball was dropped was in responding to a complaint about how the posting was specially hidden where the communicated action was how it will be shown on a different site in the future in place of acknowledging it should be visible as a normal post currently.

When the alarms are going off you're going to be slow, you're going to make the wrong decision on something minor, you're going to wish you had done x by y point in time looking back, you're going to have been imperfect. All that kind of stuff was handled fine (from what I can tell) here. The disappointment in transparency was in deflecting a presented highlight in how to fix a visibility issue instead of outright acknowledging it was a miss.

My message was/is about how that's not cool. Not that their handling of the issue itself was bad or an expectation of apology or expectation more resources should have been put on doing x, y, or z. Just that deflecting callouts on security communication issues with deferrals and redirection is not a cool way to handle security communication. They've since changed it, which is cool of them, but the damage was done with me (and maybe some others) in the meantime. Maybe in the future they handle that differently, maybe they don't, but for now I lost the trust I had that they always will, even when nobody is looking, since they didn't even when they knew people were.

Re: Gaining access to anyones Arc browser without them even visiting a website

#509

Post by hoothoot »

We looked into supporting Arc at work, unfortunately Arc is missing lots of basic security controls which are available in many other Chromium and non-Chromium browsers, these include:

+ 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.

Re: Gaining access to anyones Arc browser without them even visiting a website

#510

Post by radicaldreamer »

zo1 wrote: post #455
JumpCrisscross wrote: post #384

Earlier quoted context omitted.

> Many engineers at SV startups use Arc on a daily basis Do we have adoption statistics? It would seem prudent for the browser to be banned in professional environments. (I use Kagi's Orion browser as a personal browser on MacOS. My work is done in Firefox.) > browser bug of this severity is extremely valuable, even for a niche browser like Arc Absolutely. (Even if it were in beta.) What I'm trying to say is the $2k…

There is also 3: putting a big bounty out signals other very smart and ingenious security researchers that Arc is a lucrative opportunity to make money. Till now it's been "safe" in relative obscurity so not a lot of people focused on hacking it or gave it a lot of effort because it wasn't worth their time.

It’s already going to be under the microscope now from black hats, so unless they want a catastrophic issue to result in user harm, they better get their act together.
Post reply on HN