Worth mentioning as well that they recently raised $50M USD earlier this year, and have raised more than $128M in total; I saw several people on HN and elsewhere acting like the low payout is understandable due to it being a small team or whatever, but to me, this is so incredibly egregious knowing that information. Even though this is a dumb bug that should never have existed and is easy to fix, it does not change the fact that, not only are most horrible exploits similar in that regard, but it is still an exploit that allows you to easily compromise the user with minimal effort. It could have easily sold for six or seven figures on the gross, somehow legal 0-day marketplaces like Zerodium, used by governments and commercial spyware vendors, or to the proper-proper blackmarket for similar. Even if this particular researcher is simply a decent person and would not have considered that an option, not everyone else is, and bug bounty payouts are meant to be decent to avoid precisely that sort of thing. The idea that a company with THAT much could ever think $20,000, let alone $2,000, is fair and reasonable is just gross; to me, at worst, and I think it's not unreasonable to assume the worst in this situation, it makes it very clear that they don't care about their users whatsoever and are yet-another shit SV cash-burning pump-and-dump startup as always, or, more charitably, they are genuinely incompetent, grossly negligent, way in over their heads, and are currently too concerned with marketing and user-acquisition to actually hire people who know how to manage such a large product. I was personally likely never going to touch Arc with a 10ft pole, not only because it just isn't my personal thing in terms of UI, UX, and featureset, but also because, at the end of the day, it's still, fundamentally, yet another Blink browser with some stuff tacked on -- which is not at all productive in terms of browser diversity or internet standards -- however, unlike even Chromium or Brave, it is also totally proprietary and inauditable, essentially just leeching from the Chromium ecosystem; and to top it off, demands account registration, which to me, is generally never a great sign. But this is just the added nail in the coffin for me-it's no longer just a dumb waste of energy, but actively harmful, IMO, and I can't believe people are *still* recommending it.
Bro 20k... Its still not enough. The amount of money you can make with that vulnerability is way higher then the bounty for it. This is why vulnerabilities go 'unnoticed' for so long. They are definetly noticed, and used, before someone with ethics notices the same issue.
I think it's enough. Also, how would you make money with that vulnerability? I do believe you that it can be done, and that it is being done with other vulnerabilities in various products that are unnoticed. I can imagine it with some vulnerabilities. However, this one? Where is the potential to make money off of it?
@@matejpesl1 this is essentially remote code execution, you can get custom javascript on any victim from anywhere on any website. bank accounts? phishing from the real websites?
@@matejpesl1 its pretty simple, you target a website with credentials (like a bank) and you insert your customization JavaScript into the database with the target users ID. When the user next visits the page, the browser grabs the customization JavaScript associated with user ID and executes - your code sends the websites credentials to you on successful authentication. Just like that, you've got a way to extract credentials from anyone who's user ID can be found. And since you can personalize this to a specific person, and target literally any website to take the credentials of, I wouldn't be surprised if there were incidents of people losing their accounts 'randomly' that could be because of this. I agree, $20000 might be enough if you think the security doesn't matter much, but for a literal web browser a security vulnerability of this level is an astronomical mess up. You would think they would take the problem more seriously. I will never use this browser simply because the creators clearly don't care about security. Any user of their product could be a target to an attack like this.
3:30 Frida is a Code Injection Framework. It's JavaScript. It has access to the internal api if any object/function/methods/etc. you can use it for objective c, Java, .net, c++, c# anything.
When I saw Theo's video pushing the Arc browser, I knew to stay with Firefox. Obviously I'm not saying Theo knew this was going to happen or that he could have predicted this, it's just my crude silly heuristic for if I should use something or not. If Theo pushes something, 9 times out of 10, I should stay away. Looks like my rudeness wins the day again lol.
This is harsh but it's becoming more and more accurate. That's the problem with having trendy new tech as part of your brand. You miss the measure of time.
FRIDA injects a JavaScript runtime into an arbitrary process. It then lets you run scripts that can inspect, hook, modify, etc the process like a debugger. Essentially a process debugger script written in javascript!
We’re not. At least if you mean, “professional engineers working on Apple platforms.” Both Arc and firebase are for hobbyists and will get your project laughed out of an interview.
@@nopenoperson9118 I'm surprised they exist anymore. Their cult-leader died while refusing medical treatment in favor of Apple juice. It's a pretty bad fall.
why not production? its very usefull because its provide free tier, i will give you usecase example, you want to create backend for your android keyboard or android launcher apk for saving user account, subscribtion, etc
@@my_online_logs those that are drawn to it are rarely those which are sufficiently experienced to set up a backend that can be public facing without catastrophic results, to such a degree that they might as well be jackalopes. 90% of the people I've met that have used it to build backends have been front end people wrongly calling themselves full stack but putting security sensitive functionality in client side code. Using it for a few narrow services like notifications or login is usually less of an indicator of inevitably getting hacked than those that use it more broadly.
@@my_online_logs because of this entire article. the people drawn to these solutions are often the people that aren't prepared for these solutions. and often, when you're prepared enough for something like this, you're at the point where you can quite easily implement what firebase provides.
I have no idea why this got assigned a CVE. This is not a bug in Firebase, it’s a bug in Arc. It was bad developers not reading documentation correctly and not setting up the database structure correctly. They could’ve easily set the database structure up so boosts were a sub collection on user database documents named with their uid and only allowed users who’s uid matched the users document name to read and write from that sub collection. It’s simple. Rushed code = bad code. This sounds like a case of rushed database design, poor internal checking of the design and rushed execution
Also for the boosts they should have used a bloom filter to determine if you were on a page with a specific boost. That works by searching by a partial hash, and then the client looks at all results and finds the matching one. This does not reveal the exact site. The only problem is this is in-effective if there are very few boosts that would be returned by a given query.
Does the db even need the clear name of the website the boost is for? Client side hashing of domain + secret would be a way to anonymize the boosts at rest and make extracting browsing history a bit harder than grepping logs. Why not cache *all* boosts a user has as a background task anyway? I've had tempermonkey for years and I think I have
Just 2K? Such a low reward for a massive problem, That just tells hackers there better off bundling it on the black market, or selling it to the alphabet boys. Edit: Glad they upped it to 20k.
20k is a very fair reward, and their way of dealing with it is completely reasonable and good faith. They obviously didn't have experience dealing with this type of situation and had no bounty program in place, but they've adjusted and done that now. Even leaving an open job offer for Eva if she wants it. Everything about how this story ended was done in good faith. I don't think the takeaway here at all is that going black hat is somehow better.
@@neruneri The point is that you always want bug bounty rewards to be higher than what you could get by selling the vuln on some black market. Remember, the only difference between a security researcher and a malicious hacker is where they disclose vulnerabilities. If the rewards given by bug bounty programs are higher than black market prices, that incentivises security researchers to keep doing the right thing, and black hats (who are almost always only in it for the money) to become "security researchers."
To be fair this isn’t a SQL directly from browser to the database issue. They could have had any number of layers between the browser request and DB query and still have a bug like this. The problem is using the id given in the request from the browser.
That's the point.. at the time of the update operation (auth.uid: 1, record.uid: 1) it had permission to read/update record.uid. So it could set it to 2 and then no longer have access to it.
@@urbaniv the point is not that it is already fixed. The point is that your comment is not the fix. The fix is making the userId column unchangeable after creation
Developer: I don't want to write backend Developer: I want to just want to get JSON and not worry about it Google: here is a database Developer: yes Google: also, you'll need to monitor who can and can't make or change your data as the rest of them
I find it annoying that they don't push permission correctness harder in Firestore. This issue is trivial to prevent, but it only works if the dev knows how.
Re finding out other folks' IDs: In MMOs we used to call this 'leaking information' when they were sent to clients. Many games do it sadly. One thing I liked to do was a remap any internal ID into a current_client_session ID starting at 1. This had the added benefit of shrinking the packets (which is actually where it started), but since it doesnt leak information to the client, its better also. It technically costs CPU time too, but usually with MMOs theres a need to reduce packet size at the cost of CPU time. [With the above bug, they also allowed changing IDs they never should have, but it sounds like theyre fixing that too]
If you can access a boost, then you could create your own "worm" which will walk through the tree of referrals starting at you. Enumerating a huge number of users.
lol the var they were using was objective C I think, and it's automatically getting the type to assign from the return value of the expression on the right (I think)
Hey Prime.. outta left field but, I just wanted to thank you brotha. Youre content and sense of humor are getting me through a real bad low patch rn.. and I just appreciate you. Also, how do I join your streams? I'm sorta knew to this whole "social media universe"
15:44 I would say it depends on how you handle it. If all of the checking that could leak information is done client side then it's probably not a problem. If you're constantly querying servers then it's probably leaking what you're doing.
What a dumb vulnerability. Everything about this screams carelessness. Oh, and they should simply request all domains for which boosts exist in the user's account and then just perform the check client-side. At least then firestore wouldn't know of every single page you're visiting, only those with for which you have a boost...
Technically the security rules are "always deny" by default, and most devs immediately change it to "always allow" (as a temporary workaround to actually writing the rules)
Firebase has great tools to handle this situation, a simple rule like, `allow write: request.auth.uid == creatorID` on that boost table, and this would have been solved.
Controversial: I don't think this is flawed as much as developers are not used to it (assuming security issues are pervasive as the author says). SQL in the browser is not a problem at all. It's hardly relevant to the problem. The issue is that we've started with a full permissions model and are closing it VS a no-permissions model and are punching holes (most endpoints, from my perspective). Take a normal endpoint, no parameters. We add the code to SELECT a single thing from the database and returns it. When you started writing that function it was empty, it had no permission to do anything but return a response. Then you wrote your static SELECT in there. Now it has an unconfigurable select that allows access to the extent that that query allows by the rules of the SQL language. If you now take user input you've made an implicit permissions rule that extends to the parameters entire configuration space. If that input isn't sanetized (should be rare now, but just for example) you've extended the implicit permissions of the end point to be anything that can be SQL injected. Of course that's the extreme, I'm not saying that you're SQL injection vulnerable all the time I'm just illustrating the implicit nature of permissions being defined by the code you wrote. With the permissions system this uses, as I understand it, you could have a very similar/identical progression into low security but more controlled. Then you open it up with actually defined permissions. I've not worked with it but it seems almost trivial to make this secure. And from what I got of the description they outsourced auth and left none of that within the DB query system. And apparently gave everyone full permissions. It doesn't seem at all like a failure of the technology except perhaps it's poorly adapted to developers, they've not learned.
This is generally how it's supposed to work, it's just that the people who'd want to use Firebase for an app are generally not skilled developers and end up implementing "always allow" as a temporary workaround that becomes permanent lol
Wait so this company has a backend that is just a database in the user browser??? This is why you never break the rule "authentication and authorization must be on the backend period " aaambotb
Technically the backend is Firebase, which handles authentication/authorization, but they didn't configure it to limit access from anyone. A correctly configured Firebase instance wouldn't break this rule.
There's a hidden historical linguistics section to this video highlighting the origin of the saying "Flipping someone off" at 10:32. Great multidisciplinary content right here. Also; quick shout out to Theo for contributing to Eva's cause of making the internet a safer place.
This is why you don't let two dudes make a web browser. Web browser development has been likened to OS development. They are massive, ultra-complex projects that are beyond the scope and skill set of anything smaller than a team of about 50 people. Assuming, of course, that you want people to use your software.
Hmmm ... that is an awfully long hash to be able to brute force someone else's ID. Still a bad design of course as the key is not hidden, and I am probably misreading it, but really, if long hashes were able to be spoofed, there goes session id's, API keys, symmetric crypto keys, etc. The entire internet revolves around not being able to try every key
It's a browser that uses a different tab bar design than Chrome or Firefox or whatnot. Check it out online, it actually does quite well in the UI department.
It's a web browser made by a company creatively named The Browser Company. Arc has some fancy cloud integration features, and because of not securing things properly, they ended up with this mess. It's not a good look, but at least they seem to have handled it properly.
- On one hand it is a skill issue - On another hand, I have never seen a correctly configured Firebase instance. It's always "hey we'll set it up with "always-allow" rules temporarily and switch back later", only to never switch back. That plus nobody knows how to write Firebase rules.
@@omduggineni yeah, that's true. I guess a lot of people have the mentality that requests will never come from an external source, so they end up with a lot of loose ends
14:44 why isn't there an AI that can "find" the bugs "easily"? Just have it try every known usual vulnerability on every single part of an app and have it spit out the findings? And I don't mean bots on github hallucinating issues into projects.
The category of an invulnerability and the implementation of it are just too different For example, the [concept] of "dont store plain text password" is clear. But prj 1 could have a field call "var password", prj 2 could call it "var pwd", prj 3 may call it "var p". 100 projects and you can have 300 variable names for the password variable. How would an AI know that "var kqosj" is actually holding a password? For AI to achieve that ability, it need to be able to think, i.e. achieve consciousness. And we are not **quite** there yet
Wtf, hearing about firestore this is so obviously a bad idea Is server CPU that limited for them? Im sure the packets containing SQL are also larger than packets just asking the server to do something I'm literally just a roblox dev (with no games yet cuz im not that good) and I already know never to trust the client on anything they say, and instead the server should do it itself Who the fuck thought firestore was a good idea? edit: finished the video, good job arc switching off firestore
I feel it's a not bad either... here they forgot to change permission... like uid== authuser.uid then executes the query(something like that), otherwise, set read and write permision to off.. they forgot to turn off the read and write permissions if the id not matches
Most devs these days have no idea how to build proper backends. They use all these things like firebase and crutches to quickly pump out code that 'works', but ya.
@@vaisakh_km Of course it's their fault they forgot the permissions. The poor design of the program doesnt excuse the fact that they dont know how to use it. But a program should be designed to first assume the client is wrong and/or malicious THEN do the work requested. A protocol that allows direct database access with EXCEPTIONS is far less secure than a protocol with endpoints that allow very specific database use cases, even if its solely up to developer incompetence.
@@sick-soggy-socks-suck I think the point is more that these sorts of platforms are made to make things 'easier'. If it has some wierd way to handle auth that you need to read through 40 pages of documents so you dont make a slip up, is pretty much defeating the purpose of having these sorts of platform that are designed to make it easier,faster and i would assume, more secure.
I don't follow or watch any GeRmAnS or AmErIcAnS... Looking through my recent watchrs ... And videos... Cakes Prime 😂 WowmmOW🎉 guy with fucking FERREYGHS
@@lightningx10 I've said, deleted, that the door in the front is the back door. And TOS, the small button saying "agree". Maybe the YT goods will let this comment... How come I receive notifications for my deleted message? Just to see that they are removed? Funny.
guess they forgot to have a Mutex inside that Arc, amiright fellas?
should've used the unique_ptr browser
no they DID have a mutex T inside that arc
Thank you great CEO
Technically they just forgot to add any authentication to their database server lol
😂😂
A 2K reward is just ridiculous. This vulnerability could quickly destroy the company's reputation for good. BTW: $128 million raised from VCs
they upped it to 20k, still too low but it seems like they’re more ignorant of standards than anything
they also offered a job to the person who discovered the vulnerability
Worth mentioning as well that they recently raised $50M USD earlier this year, and have raised more than $128M in total; I saw several people on HN and elsewhere acting like the low payout is understandable due to it being a small team or whatever, but to me, this is so incredibly egregious knowing that information.
Even though this is a dumb bug that should never have existed and is easy to fix, it does not change the fact that, not only are most horrible exploits similar in that regard, but it is still an exploit that allows you to easily compromise the user with minimal effort. It could have easily sold for six or seven figures on the gross, somehow legal 0-day marketplaces like Zerodium, used by governments and commercial spyware vendors, or to the proper-proper blackmarket for similar.
Even if this particular researcher is simply a decent person and would not have considered that an option, not everyone else is, and bug bounty payouts are meant to be decent to avoid precisely that sort of thing. The idea that a company with THAT much could ever think $20,000, let alone $2,000, is fair and reasonable is just gross; to me, at worst, and I think it's not unreasonable to assume the worst in this situation, it makes it very clear that they don't care about their users whatsoever and are yet-another shit SV cash-burning pump-and-dump startup as always, or, more charitably, they are genuinely incompetent, grossly negligent, way in over their heads, and are currently too concerned with marketing and user-acquisition to actually hire people who know how to manage such a large product.
I was personally likely never going to touch Arc with a 10ft pole, not only because it just isn't my personal thing in terms of UI, UX, and featureset, but also because, at the end of the day, it's still, fundamentally, yet another Blink browser with some stuff tacked on -- which is not at all productive in terms of browser diversity or internet standards -- however, unlike even Chromium or Brave, it is also totally proprietary and inauditable, essentially just leeching from the Chromium ecosystem; and to top it off, demands account registration, which to me, is generally never a great sign. But this is just the added nail in the coffin for me-it's no longer just a dumb waste of energy, but actively harmful, IMO, and I can't believe people are *still* recommending it.
That unknow browser has money?
@@isaidstream4547 Total money raised from VC: $128 million for reskined Chrome. And they nickel and dime security researchers.
Bro 20k... Its still not enough. The amount of money you can make with that vulnerability is way higher then the bounty for it. This is why vulnerabilities go 'unnoticed' for so long. They are definetly noticed, and used, before someone with ethics notices the same issue.
I think it's enough.
Also, how would you make money with that vulnerability? I do believe you that it can be done, and that it is being done with other vulnerabilities in various products that are unnoticed. I can imagine it with some vulnerabilities. However, this one? Where is the potential to make money off of it?
@@matejpesl1 this is essentially remote code execution, you can get custom javascript on any victim from anywhere on any website. bank accounts? phishing from the real websites?
@@matejpesl1you can have custom js, you can scrape financial information from banking sites, aws logins, etc
Yeah, Arc is not a high-profile product yet. I doubt you could make a lot of money exploiting something that barely anyone has heard of yet
@@matejpesl1 its pretty simple, you target a website with credentials (like a bank) and you insert your customization JavaScript into the database with the target users ID. When the user next visits the page, the browser grabs the customization JavaScript associated with user ID and executes - your code sends the websites credentials to you on successful authentication. Just like that, you've got a way to extract credentials from anyone who's user ID can be found. And since you can personalize this to a specific person, and target literally any website to take the credentials of, I wouldn't be surprised if there were incidents of people losing their accounts 'randomly' that could be because of this. I agree, $20000 might be enough if you think the security doesn't matter much, but for a literal web browser a security vulnerability of this level is an astronomical mess up. You would think they would take the problem more seriously. I will never use this browser simply because the creators clearly don't care about security. Any user of their product could be a target to an attack like this.
MKBHD broken wallpaper app MENTIONED
Anyone got the source to this I'm super confused
@@um8078 Dude just google "mkbhd broken wallpaper app"
lol. Its so bad even their landing page was broken
3:30 Frida is a Code Injection Framework. It's JavaScript. It has access to the internal api if any object/function/methods/etc. you can use it for objective c, Java, .net, c++, c# anything.
When I saw Theo's video pushing the Arc browser, I knew to stay with Firefox. Obviously I'm not saying Theo knew this was going to happen or that he could have predicted this, it's just my crude silly heuristic for if I should use something or not. If Theo pushes something, 9 times out of 10, I should stay away. Looks like my rudeness wins the day again lol.
Yeah when I saw him recommend it and tried arc out for myself I really liked it and made it my default browser.
After this I'm done.
Yea guys i keep on saying frontend devs are not devs😅😂😂 tongue in mouth, pun intended
@@warrenarnoldmusic they have different skills lol, like ui design
This is harsh but it's becoming more and more accurate. That's the problem with having trendy new tech as part of your brand. You miss the measure of time.
FRIDA injects a JavaScript runtime into an arbitrary process. It then lets you run scripts that can inspect, hook, modify, etc the process like a debugger. Essentially a process debugger script written in javascript!
I was gonna test out Arc cause all the Apple fanboys are into it, but the fact this happened in the first place makes me never want to use this.
your first hint wasn't the fact that all the Apple fanboys are into it?
Every software had vulnerabilities, it's how they deal with it.
We’re not. At least if you mean, “professional engineers working on Apple platforms.”
Both Arc and firebase are for hobbyists and will get your project laughed out of an interview.
@@nopenoperson9118
I'm surprised they exist anymore. Their cult-leader died while refusing medical treatment in favor of Apple juice. It's a pretty bad fall.
I am an Apple fanboy and have never heard of it
Firebase is pretty much used exclusively by people that shouldn't do a production backend.
why not production? its very usefull because its provide free tier, i will give you usecase example, you want to create backend for your android keyboard or android launcher apk for saving user account, subscribtion, etc
@@my_online_logs those that are drawn to it are rarely those which are sufficiently experienced to set up a backend that can be public facing without catastrophic results, to such a degree that they might as well be jackalopes.
90% of the people I've met that have used it to build backends have been front end people wrongly calling themselves full stack but putting security sensitive functionality in client side code.
Using it for a few narrow services like notifications or login is usually less of an indicator of inevitably getting hacked than those that use it more broadly.
@@my_online_logs because of this entire article. the people drawn to these solutions are often the people that aren't prepared for these solutions. and often, when you're prepared enough for something like this, you're at the point where you can quite easily implement what firebase provides.
@@my_online_logsThe use case you gave is exactly what arc was doing that lead to this issue
Objective C strikes again. Quite a throwback!
What does this have to do with Objective C? The vulnerability isn’t there.
@@avwie132 It's because the kind of people who still use objective C are completely off their rockers
My OCD everytime he highlights some text and skips the first and last letter of the sentence🤯
Always double click the mouse could have soulved za isssue
@@ninetydirectory3798he does it intentionally
At least he *usually* symmetrically highlights; one character from both ends of the highlight
99% of the time I try to select from the first word it ends up wrapping to the previous paragraph or whole page
Easier hit rate... sometimes it selects the whole page if you don't get it spot on, right?
I have no idea why this got assigned a CVE. This is not a bug in Firebase, it’s a bug in Arc. It was bad developers not reading documentation correctly and not setting up the database structure correctly.
They could’ve easily set the database structure up so boosts were a sub collection on user database documents named with their uid and only allowed users who’s uid matched the users document name to read and write from that sub collection.
It’s simple. Rushed code = bad code. This sounds like a case of rushed database design, poor internal checking of the design and rushed execution
Also for the boosts they should have used a bloom filter to determine if you were on a page with a specific boost. That works by searching by a partial hash, and then the client looks at all results and finds the matching one. This does not reveal the exact site. The only problem is this is in-effective if there are very few boosts that would be returned by a given query.
Does the db even need the clear name of the website the boost is for? Client side hashing of domain + secret would be a way to anonymize the boosts at rest and make extracting browsing history a bit harder than grepping logs.
Why not cache *all* boosts a user has as a background task anyway? I've had tempermonkey for years and I think I have
Just 2K? Such a low reward for a massive problem, That just tells hackers there better off bundling it on the black market, or selling it to the alphabet boys. Edit: Glad they upped it to 20k.
they decided to increase it to 20k
20k is a very fair reward, and their way of dealing with it is completely reasonable and good faith. They obviously didn't have experience dealing with this type of situation and had no bounty program in place, but they've adjusted and done that now. Even leaving an open job offer for Eva if she wants it. Everything about how this story ended was done in good faith. I don't think the takeaway here at all is that going black hat is somehow better.
@@neruneri at first it was 2k
@@neruneri The point is that you always want bug bounty rewards to be higher than what you could get by selling the vuln on some black market. Remember, the only difference between a security researcher and a malicious hacker is where they disclose vulnerabilities. If the rewards given by bug bounty programs are higher than black market prices, that incentivises security researchers to keep doing the right thing, and black hats (who are almost always only in it for the money) to become "security researchers."
Why would you expect more from a meme browser?
To be fair this isn’t a SQL directly from browser to the database issue. They could have had any number of layers between the browser request and DB query and still have a bug like this. The problem is using the id given in the request from the browser.
That's really the basic security rule:
Write, read if auth.uid==uid in doc
That's the point.. at the time of the update operation (auth.uid: 1, record.uid: 1) it had permission to read/update record.uid. So it could set it to 2 and then no longer have access to it.
@@k225 yeah posted it during the video at the end it's explained that it's already fixed
@@urbaniv the point is not that it is already fixed.
The point is that your comment is not the fix. The fix is making the userId column unchangeable after creation
You missed the WHOLE POINT 😂
@@artistry7919 AHH right. Of course.
Sounds like something oblivious Mac devs would do. That's why you don't use some random browsers, even if they're Chromium-based.
Developer: I don't want to write backend
Developer: I want to just want to get JSON and not worry about it
Google: here is a database
Developer: yes
Google: also, you'll need to monitor who can and can't make or change your data as the rest of them
IoT level software engineering, but for your browser. What could go wrong?
Where is the cat that follows cursor ?? i miss it :(
I find it annoying that they don't push permission correctness harder in Firestore. This issue is trivial to prevent, but it only works if the dev knows how.
Re finding out other folks' IDs: In MMOs we used to call this 'leaking information' when they were sent to clients. Many games do it sadly.
One thing I liked to do was a remap any internal ID into a current_client_session ID starting at 1. This had the added benefit of shrinking the packets (which is actually where it started), but since it doesnt leak information to the client, its better also. It technically costs CPU time too, but usually with MMOs theres a need to reduce packet size at the cost of CPU time.
[With the above bug, they also allowed changing IDs they never should have, but it sounds like theyre fixing that too]
If you can access a boost, then you could create your own "worm" which will walk through the tree of referrals starting at you. Enumerating a huge number of users.
Url safe version of base64 has no equal signs. Also if it's base64 encoded you can decode and see the exact ID.
2k is so little for how serious that vulnerability was. I'm glad I'm not using Arc atm.
lol the var they were using was objective C I think, and it's automatically getting the type to assign from the return value of the expression on the right (I think)
Was not expecting that based callout 18:18
I barely use JS and know that the var's should be const's as pointed out near the end of the vod.
Hey Prime.. outta left field but, I just wanted to thank you brotha. Youre content and sense of humor are getting me through a real bad low patch rn.. and I just appreciate you.
Also, how do I join your streams? I'm sorta knew to this whole "social media universe"
15:44 I would say it depends on how you handle it. If all of the checking that could leak information is done client side then it's probably not a problem. If you're constantly querying servers then it's probably leaking what you're doing.
What a dumb vulnerability. Everything about this screams carelessness. Oh, and they should simply request all domains for which boosts exist in the user's account and then just perform the check client-side. At least then firestore wouldn't know of every single page you're visiting, only those with for which you have a boost...
Yeah, local storage + sync would be way way better overall!
@@deidyomega Agreed, and sync should also be optional.
SQL Injection by default?
Only total noobs can make such a system up.
Technically the security rules are "always deny" by default, and most devs immediately change it to "always allow" (as a temporary workaround to actually writing the rules)
Firebase has great tools to handle this situation, a simple rule like, `allow write: request.auth.uid == creatorID` on that boost table, and this would have been solved.
But this is actually a one minute fix for arc so I don't think it's still possible.
They just have to update their Firestore security rules
People put a Fedora in their head? I didn't know Neuralink could boot Linux already.
where is the running kitty?
Controversial: I don't think this is flawed as much as developers are not used to it (assuming security issues are pervasive as the author says).
SQL in the browser is not a problem at all. It's hardly relevant to the problem. The issue is that we've started with a full permissions model and are closing it VS a no-permissions model and are punching holes (most endpoints, from my perspective).
Take a normal endpoint, no parameters. We add the code to SELECT a single thing from the database and returns it. When you started writing that function it was empty, it had no permission to do anything but return a response. Then you wrote your static SELECT in there. Now it has an unconfigurable select that allows access to the extent that that query allows by the rules of the SQL language.
If you now take user input you've made an implicit permissions rule that extends to the parameters entire configuration space. If that input isn't sanetized (should be rare now, but just for example) you've extended the implicit permissions of the end point to be anything that can be SQL injected. Of course that's the extreme, I'm not saying that you're SQL injection vulnerable all the time I'm just illustrating the implicit nature of permissions being defined by the code you wrote.
With the permissions system this uses, as I understand it, you could have a very similar/identical progression into low security but more controlled. Then you open it up with actually defined permissions. I've not worked with it but it seems almost trivial to make this secure. And from what I got of the description they outsourced auth and left none of that within the DB query system. And apparently gave everyone full permissions.
It doesn't seem at all like a failure of the technology except perhaps it's poorly adapted to developers, they've not learned.
This is generally how it's supposed to work, it's just that the people who'd want to use Firebase for an app are generally not skilled developers and end up implementing "always allow" as a temporary workaround that becomes permanent lol
It's not a week, it's less than 30 hours from report to patch.
It looks like I am in a time machine reading news about firefox.
Man after reading the title I was worried there for a moment. But thankfully it's just another The Browser Company W
agree about configuration, it is not as flexible as if it was implemented as code. config is good for only defining constants and enabling flags
11:10
Thats just a constraint of the feature. They're storing tampermonkey scripts for their users. Certifiably not crazy. Perhaps ill-advised?
Wait so this company has a backend that is just a database in the user browser???
This is why you never break the rule "authentication and authorization must be on the backend period " aaambotb
Technically the backend is Firebase, which handles authentication/authorization, but they didn't configure it to limit access from anyone. A correctly configured Firebase instance wouldn't break this rule.
There's a hidden historical linguistics section to this video highlighting the origin of the saying "Flipping someone off" at 10:32. Great multidisciplinary content right here. Also; quick shout out to Theo for contributing to Eva's cause of making the internet a safer place.
what
These people have to business making a browser.
I guess I should switch browsers... Our company just banned Firefox for being "insecure" (wtf) so not sure where to go now, edge?
I think Gecko engine has slightly worse sandbox security than Blink
I knew something was off about Arc
This is why you don't let two dudes make a web browser. Web browser development has been likened to OS development. They are massive, ultra-complex projects that are beyond the scope and skill set of anything smaller than a team of about 50 people. Assuming, of course, that you want people to use your software.
The arc team is over 50 ppl
privacy > security.. POGGERS
Arc doesn't even have a valid business model
Can't download arc on my windows.
Hmmm ... that is an awfully long hash to be able to brute force someone else's ID. Still a bad design of course as the key is not hidden, and I am probably misreading it, but really, if long hashes were able to be spoofed, there goes session id's, API keys, symmetric crypto keys, etc. The entire internet revolves around not being able to try every key
Thank you const-agen!
Any assessmnet on Talon browser
Prime needs to stop reading and make more projects smh
The fact that award was only 2k is mad. It should be somwhere in 10x - 100x range.
UPD: 20k is at least something.
On the black market this would've been worth $100k easy
base64 converts 3 chars to 4 chars. = is used as padding when not mult of 3 bytes.
lol that var and cost at end
Firebase was the problem...LOL
what your favorite color prime?
theo already made a good video on this
WTF is Arc? Why don't you explain it? Why do you assume any of us knows what Arc is?
It's an Apple fanboy browser.
It's a browser that uses a different tab bar design than Chrome or Firefox or whatnot. Check it out online, it actually does quite well in the UI department.
It's a web browser made by a company creatively named The Browser Company. Arc has some fancy cloud integration features, and because of not securing things properly, they ended up with this mess. It's not a good look, but at least they seem to have handled it properly.
0:58 man in the middle proxy
4:50 don't tell him what's react-native
Sounds more like a skill issue, rather than a firestore issue (9:20 in)
- On one hand it is a skill issue
- On another hand, I have never seen a correctly configured Firebase instance. It's always "hey we'll set it up with "always-allow" rules temporarily and switch back later", only to never switch back. That plus nobody knows how to write Firebase rules.
@@omduggineni yeah, that's true. I guess a lot of people have the mentality that requests will never come from an external source, so they end up with a lot of loose ends
Esel means Donkey in German- just saying
For a startup a 100k is crazy.
finding are difficult. grammars is easy.
this guy is interesting!
00:50 why would you pretend not to know MKBHD comeon
Why is everyone competing and commenting that they're first?
This aint no competition, girls!
7:20 That's fucking insane
Thank god
Hoooly mitm
arc needs an account to be used lol
LOL I love flip 😂
As always with hyped useless shit like that
14:44 why isn't there an AI that can "find" the bugs "easily"? Just have it try every known usual vulnerability on every single part of an app and have it spit out the findings? And I don't mean bots on github hallucinating issues into projects.
GPT Enterprise.
probably because they keep hallucinating
The category of an invulnerability and the implementation of it are just too different
For example, the [concept] of "dont store plain text password" is clear. But prj 1 could have a field call "var password", prj 2 could call it "var pwd", prj 3 may call it "var p".
100 projects and you can have 300 variable names for the password variable. How would an AI know that "var kqosj" is actually holding a password?
For AI to achieve that ability, it need to be able to think, i.e. achieve consciousness. And we are not **quite** there yet
I'm -1st. Negative first.
You are now last due to wrapping
@@electric26 shit
I ate socks 😊
18:58 ☝️🤓💀
Used ARC for a couple of days and hated it, the UI/UX for it was so bad
Firestarter... sorry, firebase is silly. People behave and don't use, please!
Wtf, hearing about firestore this is so obviously a bad idea
Is server CPU that limited for them? Im sure the packets containing SQL are also larger than packets just asking the server to do something
I'm literally just a roblox dev (with no games yet cuz im not that good) and I already know never to trust the client on anything they say, and instead the server should do it itself
Who the fuck thought firestore was a good idea?
edit: finished the video, good job arc switching off firestore
I feel it's a not bad either... here they forgot to change permission...
like uid== authuser.uid then executes the query(something like that), otherwise, set read and write permision to off.. they forgot to turn off the read and write permissions if the id not matches
Most devs these days have no idea how to build proper backends. They use all these things like firebase and crutches to quickly pump out code that 'works', but ya.
@@vaisakh_km Of course it's their fault they forgot the permissions. The poor design of the program doesnt excuse the fact that they dont know how to use it. But a program should be designed to first assume the client is wrong and/or malicious THEN do the work requested. A protocol that allows direct database access with EXCEPTIONS is far less secure than a protocol with endpoints that allow very specific database use cases, even if its solely up to developer incompetence.
Also it's not literally SQL, it's Google's own query system. Firestore is a NoSQL database.
@@sick-soggy-socks-suck I think the point is more that these sorts of platforms are made to make things 'easier'.
If it has some wierd way to handle auth that you need to read through 40 pages of documents so you dont make a slip up, is pretty much defeating the purpose of having these sorts of platform that are designed to make it easier,faster and i would assume, more secure.
Why can't we just use VPS or IaaS
Maybe not expose the userUids left and right?
Typical programmer slop. Firebase should be banned from the net.
It's nothing to do with firebase and everything to do with who didn't write proper security rules.
I'm not first
All browsers have critical vulnerabilities, Chrome, Edge, FireFox... Quite frequently. Thats why they all auto-update.
that was a authentication problem because of using default firebase auth by arc devs
Those are caused by obscure bugs in the JS engine not plain stupidity.
God can this guy finish a single sentence before moving to the next one?? It's so frustrating to listen to him
He has ADHD be nice
he had an "ice" prob as a youngin, so he prob refuses to medicate with ADHD meds today
Mom I'm first!
But your dad wasn't
First here 😁
Confused, he looks on youtube an american moustache man talking about some non sense
I don't follow or watch any GeRmAnS or AmErIcAnS... Looking through my recent watchrs ... And videos...
Cakes
Prime 😂
WowmmOW🎉 guy with fucking FERREYGHS
are you having a stroke?
@@LunarLambda OMFG, I think I might be 🤣🤣🤣🤣
and that's why google chrome reigns supreme
Yeah the backdoors are a feature :)
@@lightningx10 THe back door is the front door. At least Mozilla's revenue is 95% from google...
💀
@@lightningx10 I've said, deleted, that the door in the front is the back door. And TOS, the small button saying "agree".
Maybe the YT goods will let this comment...
How come I receive notifications for my deleted message? Just to see that they are removed? Funny.
Only 2000$ should have conctacted mossad instead