How to gain code execution on hundreds of millions of people and popular apps • Hacker News Board

Re: How to gain code execution on hundreds of millions of people and popular apps

#251

Post by prophesi » Sat, Mar 01, 2025, 5:43 PM UTC

999900000999 wrote: post #233

prophesi wrote: post #126

Earlier quoted context omitted.

I think that's throwing the baby out with the bathwater; sane defaults are still an important thing to think about when developing a product. And for something as important as a database, which usually requires authentication or storing personal information, let your tutorials focus on these pain points instead of the promise of a database-driven app with only clientside code. It's awesome, but I think it deserves th…

I don't know what exactly happened here, but Firebase has two defaults. Test access rules which auto expire and are insecure, or production rules which require auth. If you do something stupid, like keep ignoring the insecure warning and updating them so they don't expire, that's your fault. In no other industry do workers blame their tools.

The issue usually lies in there not being enough security rules in place, not in keeping insecure rules active. For instance, for the Arc incident which we were given more information on, it was due to not having a security rule in place to prevent unauthorized users from updating the user_id on Arc Boosts in the Firestore.

Go into any other industry and hear when they say, "shoot yourself in the foot", and you've likely stumbled upon a situation where they blame their tools for making it too easy to do the wrong thing.

Re: How to gain code execution on hundreds of millions of people and popular apps

#252

Post by dingdingdang » Sat, Mar 01, 2025, 6:07 PM UTC

xrisk wrote: post #214

pjerem wrote: post #207

Earlier quoted context omitted.

And that's why I said "apart for Linux". Where are the package maintainers on the OSes everyone uses ? (and don't think that's sarcasm, I'm writing this comment on my linux desktop).

Homebrew and chocolatey?

My exact thought as well, simply point the user to a well established and proper channel for auto updates and then the dev simply needs to upload/release to said repos when a new version is put out. As an aside: Chocolatey is currently the only (stable/solid) way to consistently keep things up to date on the Win platform in my book.

Re: How to gain code execution on hundreds of millions of people and popular apps

#253

Post by 999900000999 » Sat, Mar 01, 2025, 6:09 PM UTC

prophesi wrote: post #251

999900000999 wrote: post #233

Earlier quoted context omitted.

I don't know what exactly happened here, but Firebase has two defaults. Test access rules which auto expire and are insecure, or production rules which require auth. If you do something stupid, like keep ignoring the insecure warning and updating them so they don't expire, that's your fault. In no other industry do workers blame their tools.

The issue usually lies in there not being enough security rules in place, not in keeping insecure rules active. For instance, for the Arc incident which we were given more information on, it was due to not having a security rule in place to prevent unauthorized users from updating the user_id on Arc Boosts in the Firestore. Go into any other industry and hear when they say, "shoot yourself in the foot", and you've li…

If you don't setup any access rules in Firebase, by default it'll deny access.

This means someone setup these rules improperly. Even if, you're responsible for the tools you use. We're a bunch of people getting paid 150k+ to type. It's not out of the question to read documentation and at a minimum understand how things work.

That said I don't completely disagree with you, if Firebase enables reckless behavior maybe it's not a good tool for production...

Re: How to gain code execution on hundreds of millions of people and popular apps

#254

Post by prophesi » Sat, Mar 01, 2025, 6:35 PM UTC

999900000999 wrote: post #253

prophesi wrote: post #251

Earlier quoted context omitted.

The issue usually lies in there not being enough security rules in place, not in keeping insecure rules active. For instance, for the Arc incident which we were given more information on, it was due to not having a security rule in place to prevent unauthorized users from updating the user_id on Arc Boosts in the Firestore. Go into any other industry and hear when they say, "shoot yourself in the foot", and you've li…

If you don't setup any access rules in Firebase, by default it'll deny access. This means someone setup these rules improperly. Even if, you're responsible for the tools you use. We're a bunch of people getting paid 150k+ to type. It's not out of the question to read documentation and at a minimum understand how things work. That said I don't completely disagree with you, if Firebase enables reckless behavior maybe i…

And I don't necessarily disagree either; good callout that it _was_ about improperly configured ACL's, I meant more that it wasn't related to keeping test rules alive.

For 150k+ salaries, frontend dev salaries are generally a lot less than their backend counterparts. And scrappy startups might not have cash for competitive salaries or senior engineers. I think these are a few of the reasons why Firebase becomes dangerous.

Re: How to gain code execution on hundreds of millions of people and popular apps

#255

Post by AzzyHN » Sat, Mar 01, 2025, 7:08 PM UTC

davej wrote: post #12

spudlyo wrote: post #9

Earlier quoted context omitted.

> cannot happen again. Hubris. Does not inspire confidence. > We resolved the vulnerability within 26 hours of its initial report, and additional security audits were completed by February 2025. After reading the vulnerability report, I am impressed at how quickly you guys jumped on the fix, so kudos. Did the security audit lead to any significant remediation work? If you weren't following PoLP, I wonder what else ma…

Fair point. Perhaps better phrased as "to ensure this scenario can't recur.". I'll edit my post. Yes, we re-architected our build container as part of remediation efforts, it was quite significant.

You're still doing better than many larger teams handling larger projects :D

Re: How to gain code execution on hundreds of millions of people and popular apps

#256

Post by 999900000999 » Sat, Mar 01, 2025, 7:09 PM UTC

prophesi wrote: post #254

999900000999 wrote: post #253

Earlier quoted context omitted.

If you don't setup any access rules in Firebase, by default it'll deny access. This means someone setup these rules improperly. Even if, you're responsible for the tools you use. We're a bunch of people getting paid 150k+ to type. It's not out of the question to read documentation and at a minimum understand how things work. That said I don't completely disagree with you, if Firebase enables reckless behavior maybe i…

And I don't necessarily disagree either; good callout that it _was_ about improperly configured ACL's, I meant more that it wasn't related to keeping test rules alive. For 150k+ salaries, frontend dev salaries are generally a lot less than their backend counterparts. And scrappy startups might not have cash for competitive salaries or senior engineers. I think these are a few of the reasons why Firebase becomes dange…

150k is more than a fire fighter in San Francisco.

https://sf-fire.org/employment-opportunities/h2-firefighter

I don't think it's out of the question to expect professionalism at 150k. These are VC funded companies, not a couple of college kids scraping together a prototype.

Then again, if I was a CTO seeing stories like this I'd be inclined to NOT use Firebase. I'm actually using Supabase right now since I don't like vendor lock in. Deploying Supabase manually is really difficult, but it is an option.

I imagine if I ever run a serious company, which I don't think will ever happen, I would take something like Supabase and run it on prem with some manner of enhanced security.

It's interesting though... For decades the industry has been trying to push this narrative that you don't need servers. You can handle everything using some magic platform, and throw in a couple of custom lambda functions when you need to execute logic.

Parse, Firebase, Appwrite and dozens of others emerged to fill this niche.

ToDesktop, provides even another layer of abstraction. We don't want to handle our own app updates, cool let someone else do it. That someone else doesn't want to manage their own backend, cool let someone else do it.

You end up with multiple layers of potential vulnerabilities which shouldn't exist... Cursor, Arc, etc could run their own update servers.

Maybe the solution is a Steam like distribution platform. Or just using Steam itself. That's a 30% cut to let someone else figure out your app distribution...

Re: How to gain code execution on hundreds of millions of people and popular apps

#257

Post by zahlman » Sat, Mar 01, 2025, 7:11 PM UTC

TheDong wrote: post #32

mcoliver wrote: post #29

"i wanted to get on the machine where the application gets built and the easiest way to do this would be a postinstall script in package.json, so i did that with a simple reverse shell payload" Just want to make sure I understand this. They made a hello world app and submitted it to todesktop with a post install script that opened a reverse shell on the todesktop build machine? Maybe I missed it but that shouldn't be…

In what world do you have a machine which downloads source code to build it, but doesn't have outbound internet access so it can't download source code or build dependencies? Like, effectively the "build machine" here is a locked down docker container that runs "git clone && npm build", right? How do you do either of those activities without outbound network access? And outbound network access is enough on its own to…

> The miss here isn't that the build container had network access, it's that the build container both ran untrusted code, and had access to secrets.

If you're providing a build container service then you pretty much have to run untrusted code (the customer's) in the container, yes? So then the problem is really just the bad Firebase config... ?

Re: How to gain code execution on hundreds of millions of people and popular apps

#258

Post by hinkley » Sat, Mar 01, 2025, 7:11 PM UTC

felixrieseberg wrote: post #31

As an Electron maintainer, I'll re-iterate a warning I've told many people before: Your auto-updater and the underlying code-signing and notarization mechanisms are sacred . The recovery mechanisms for the entire system are extremely painful and often require embarrassing emails to customers. A compromised code-sign certificate is close to the top of my personal nightmares. Dave and toDesktop have build a product tha…

Code signing is a really excellent place to look at ponying up the money for one of those hardware security modules that triggers sticker shock. The ones on their own PCI card with potted chips and optional Byzantine Generals access cards and consultants wearing ties. It’s cheaper than blowing six months of developer time trying to fake it (remember it will always take you twice as long as you think it will)

I built one code signing system after being the “rubber duck” for a gentleman who built another, and both used HSM cards and not cheap ones. Not those shitty little USB ones. One protected cellphones, the other protected commercial aviation.

Re: How to gain code execution on hundreds of millions of people and popular apps

#259

Post by zahlman » Sat, Mar 01, 2025, 7:19 PM UTC

arccy wrote: post #34

TheDong wrote: post #32

Earlier quoted context omitted.

In what world do you have a machine which downloads source code to build it, but doesn't have outbound internet access so it can't download source code or build dependencies? Like, effectively the "build machine" here is a locked down docker container that runs "git clone && npm build", right? How do you do either of those activities without outbound network access? And outbound network access is enough on its own to…

It's common, doesn't mean it's secure. A lot of linux distros in their packaging will separate download (allows outbound to fetch dependencies), from build (no outside access). Unfortunately, in some ecosystems, even downloading packages using the native package managers is unsafe because of postinstall scripts or equivalent.

>Unfortunately, in some ecosystems, even downloading packages using the native package managers is unsafe because of postinstall scripts or equivalent.

Funny you should mention this because I was just psyching myself up to submit my blog piece from last night on the topic.

In Python, downloading packages using the native package installer (Pip, which really doesn't itself do anything that could be called package management) is unsafe because of build scripts - unless you tell it to only accept pre-built packages, defeating the point of the systems these Linux distros are using. (I assume/hope people in this position are aware of the problem and have rigged up another solution with the API. In the post I commented that I don't know of such solutions being publicly available, but surely they exist somewhere.)

You'd be justified in wondering why the build script runs when you only ask to download the package. It's mainly because of the historically atrocious approach to metadata (and all the legacy packages for which installation is still supported). But from reading the issue trackers, it seems like the code paths aren't especially easy to disentangle, either - since they've gone so long with the assumption baked in that the problem isn't really solvable.

In other HN posts I've complained about people pointing out things in the Python packaging ecosystem that aren't really problems. But this really is one.

https://zahlman.github.io/posts/2025/02/28/python-packaging-...

Re: How to gain code execution on hundreds of millions of people and popular apps

#260

Post by worewood » Sat, Mar 01, 2025, 7:49 PM UTC

Hackbraten wrote: post #149

RadiozRadioz wrote: post #132

Earlier quoted context omitted.

How about we don't build an auto-updater? Maybe some apps require an extremely tight coupling with a server, but we should try our best to release complete software to users that will work as close to forever as possible. Touching files on a user's system should be treated as a rare special occurrence. If a server is involved with the app, build a stable interface and think long and hard about every change. Meticulou…

> Maybe some apps require an extremely tight coupling with a server, but we should try our best to release complete software to users that will work as close to forever as possible. That sounds like a good idea. Unless you’re the vendor, and instead of 1000 support requests for version N, you’re now facing 100 support requests for version N, 100 for N−1, 100 for N−2, …, and 100 for N−9.

Besides what others said, realistically, the effort to support N versions is not O(n). I think it's something like O(log n), because code will largely be shared between versions - you're not doing a rewrite every release.