Live data from Hacker News

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

kibty.town

231–240 of 350 posts

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

#231

Earlier quoted context omitted.

This one is right. Have a shoe-box key, a key which is copied 2*N (redundancy) times and N copies are stored in 2 shoe-boxes. It can be on tape, or optical, or silicon, or paper. This key always stays offline. This is your rootiest of root keys in your products, and almost nothing is signed by it. The next key down which the shoe-box key signs (ideally, the only thing) is for all intents and purposes your acting "roo…

> It can be on tape, or optical, or silicon, or paper. You can pick up a hardware security module for a few thousand bucks. No excuse not to.

I see a good excuse right there: the few thousand bucks.

I'd rather one the most reliable and cheap hardware security model we know of: paper.

Print a bunch of QR/datamatrix codes with your key. Keep one in a fireproof safe in your house, and another one elsewhere.

Total cost: ~$0.1 (+ the multipurpose safe, if needed)

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

#232
post #222

Earlier quoted context omitted.

> How about we don't build an auto-updater? Sure. I’d rather have it be provided by the platform. It’s a lot of work to maintain for 5 OSs (3 desktop, 2 mobile). > we should try our best to release complete software to users that will work as close to forever as possible This isn’t feasible. Last I tried to support old systems on my app, the vendor (Apple) had stopped supporting and didn’t even provide free VMs. Wind…

> file transfers. And I’m supposed to not touch files? I'm pretty sure you know what I meant, it's obvious from context. System program files. The files that are managed by your user's package manager (and by extension their IT department)

There isn’t a package manager in many cases: windows store requires a MS account. macOS app store nerfs apps by sandbox restrictions. Linux has so many flavors of package managers it’s death by 1000 paper cuts. None of the major bundlers like flutter, electron and tauri support all these package managers and/or app stores. Let alone running the infrastructure for it.

Which leaves you with self-updaters. I definitely agree ideally it shouldn’t be the applications job to update itself. But we don’t live in that world atm. At the very least you need to check for updates and EOL circuit breakers for apps that aren’t forever- local only apps. Which is not a niche use-case even if local-first infra was mature and widely adopted, which it very much isn’t.

Anyway, my app works without internet, pulls no business logic at runtime (live updates) and it uses e2ee for privacy. That’s way more than the average ad-funded bait-and-switch ware that plague the majority of commercial software today. I wish I didn’t have to worry about updates, but the path to less worries and healthy ecosystem is not to build bug-free forever-software on top of a constantly moving substrate provided largely by corporations with multiple orders of magnitude more funding than the average software development company.

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

#233

Earlier quoted context omitted.

What if I need to hack together a POC for 3 people to look at. It's my responsibility to make sure when we scale from 3 users to 30k users we take security seriously. As my old auto shop teacher used to say, if you try to idiot proof something they'll build a better idiot. Even if Google warns you in big bold print "YOU ARE DOING SOMETHING INSECURE", someone out there is going to click deploy anyway. You're arguing G…

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.

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

#234

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…

This one is right. Have a shoe-box key, a key which is copied 2*N (redundancy) times and N copies are stored in 2 shoe-boxes. It can be on tape, or optical, or silicon, or paper. This key always stays offline. This is your rootiest of root keys in your products, and almost nothing is signed by it. The next key down which the shoe-box key signs (ideally, the only thing) is for all intents and purposes your acting "roo…

I mean sure but is that possible for OS builds? Generally you will generate a private key, get a cert for it, give it to Apple so they sign it with their key and then you use the private key to sign your build. I have never seen a guide do a two level process and I am nof convinced it is allowed.

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

#235

Earlier quoted context omitted.

> It can be on tape, or optical, or silicon, or paper. You can pick up a hardware security module for a few thousand bucks. No excuse not to.

I see a good excuse right there: the few thousand bucks. I'd rather one the most reliable and cheap hardware security model we know of: paper. Print a bunch of QR/datamatrix codes with your key. Keep one in a fireproof safe in your house, and another one elsewhere. Total cost: ~$0.1 (+ the multipurpose safe, if needed)

Printers often have hard drives with cached pages

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

#236

Earlier quoted context omitted.

I see a good excuse right there: the few thousand bucks. I'd rather one the most reliable and cheap hardware security model we know of: paper. Print a bunch of QR/datamatrix codes with your key. Keep one in a fireproof safe in your house, and another one elsewhere. Total cost: ~$0.1 (+ the multipurpose safe, if needed)

Printers often have hard drives with cached pages

That's why you buy a printer, then destroy it with a baseball bat after you print.

It is a bit expensive when it gets to 5-10 printers but still cheaper than the thousands.

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

#237

Earlier quoted context omitted.

Then you should have to click a big red button labelled "Enable insecure mode". Defaults should be secure. Kind of blows my mind people still don't get this.

I’ve seen devs deploy production software with the admin password being “password”. I don’t think you are listening when they are saying “they’ll build a better idiot”.

Right because nobody ever makes a mistake.

That's why we don't have seatbelts of safety harnesses or helmets or RCDs. There's always going to be an idiot that drives without a seatbelt so why bother at all right?

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

#238
As usual, I read the comments here first. I'm glad I read the article though because the comments here have pretty much nothing to do with the vulnerability. Here's a summary because the article actually jumps over explaining the vulnerability in the gap between two paragraphs:

This service is a kind of "app store" for JS applications installed on desktop machines. Their service hosts download assets, with a small installer/updater application running on the users' desktop that pulls from the download assets.

The vulnerability worked like this: the way application publishers interact with the service is to hand it a typical JS application source code repo, which the service builds, in a container in typical CI fashion. Therefore the app publisher has complete control over the build environment.

Meanwhile, the service performs security-critical operations inside that same container, using credentials from the container image. Furthermore, the key material used to perform these operations is valid for all applications, not just the one being built.

These two properties of the system: 1. build system trusts the application publisher (typical, not too surprising) and 2. build environment holds secrets that allow compromise of the entire system (not typical, very surprising), over all publishers not just the current one, allow a malicious app publisher to subvert other publishers' applications.

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

#239

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…

> No magic.

There's plenty of magic. I think that Electron Forge does too many things, like trying to be the bundler. Is it possible to set up a custom build system / bundling with it or are you forced to use Vite? I guess that even if you can, you pull all those dependencies when you install it and naturally you can't opt out from that. Those dev dependencies involved in the build process are higher impact than some production dependencies that run in a sandboxed tab process (because a tiny malicious dependency could insert any code into the app's fully privileged process). I have not shipped my app yet, but I am betting on ESBuild (because it's just one Go binary) and Electron Builder (electron.build)

Post reply on HN