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

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

kibty.town

Post reply on HN
Print view View original

221–230 of 350 posts

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

#221

Post by rustcleaner »

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…

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 "root certificate authority" key running hot in whatever highly secure signing enclave you design for any other ordinary root CA setup. Then continue from there.

Your hot and running root CA could get totally pwned, and as long as you had come to Jesus with your shoe-box key and religiously never ever interacted with it or put it online in any way, you can sign a new acting root CA key with it and sign a revocation for the old one. Then put the shoe-box away.

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

#222

Post by klabb3 »

RadiozRadioz wrote: post #132
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…

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…

> 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. Windows 10 is scheduled for non-support this year (afaik). On Linux glibc or gtk will mess with any GUI app after a few years. If Microsoft, Google and Apple can’t, why the hell should I as a solo app developer? Plus, I have 5 platforms to worry about, they only have their own.

> Touching files on a user's system should be treated as a rare special occurrence.

Huh? That’s why I built an app and not a website in the first place. My app is networked both p2p and to api and does file transfers. And I’m supposed to not touch files?

> If a server is involved with the app, build a stable interface and think long and hard about every change.

Believe me, I do. These changes are as scary as database migrations. But like those, you can't avoid them forever. And for those cases, you need at the very least to let the user know what’s happening. That’s half of the update infrastructure.

Big picture, I can agree with the sentiment that ship fast culture has gone too far with apps and also we rely on cloud way too much. That’s what the local first movement is about.

At the same time, I disagree with the generalization seemingly based on a narrow stereotype of an app. For most non-tech users, non-disruptive background updates are ideal. This is what iOS does overnight when charging and on WiFi.

I have nothing against disabling auto updates for those who like to update their own software, but as a default it would lead to massive amounts of stale non-working software.

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

#223

Post by withinboredom »

IshKebab wrote: post #188
999900000999 wrote: post #96

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…

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

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

#224

Post by withinboredom »

IshKebab wrote: post #189
cdmyrm wrote: post #163

Earlier quoted context omitted.

Should we outlaw C because it lets you dereference null pointers, too?

Erm yes! Even the White House has said that. The only reason we didn't for so long was because we didn't have a viable alternative. Now we do, we should absolutely stop writing C.

The white house recently said a lot of things. But of all things, I don’t think they’re even qualified to have an opinion about software, or medical advice, or… well, anything that generally requires an expert.

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

#225

Post by withinboredom »

TheDong wrote: post #73
fc417fc802 wrote: post #55

Earlier quoted context omitted.

If you don't network isolate your build tooling then how do you have any confidence that your inputs are what you believe them to be? I run my build tools in a network namespace with no connection to the outside world. The dependencies are whatever I explicitly checked into the repo or otherwise placed within the directory tree.

You don't have any confidence beyond what lockfiles give you (which is to say the npm postinstall scripts could be very impure, non-hermetic, and output random strings). But if you require users to vendor all their dependencies, fully isolate all network traffic during build, be perfectly pure and reproducible and hermetic, presumably use nix/bazel/etc... well, you won't have any users. If you want a perfectly secure…

This is npm with all dependencies stored in a directory. Check them in. You do code review your dependencies right? Everywhere I’ve worked in the last 10 years has required this. There is no fetching of dependencies in builds. Granted, this is harder to pull off if your devs are developing on a totally different cpu architecture than production (fuck you apple).

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

#226

Post by buran77 »

sigmoid10 wrote: post #215
PeterStuer wrote: post #204

Earlier quoted context omitted.

Sounds like you come from the B2B, consultancyware or 6÷ figure/year license world. For the vast realm of all your suggestions are completely unviable.

And it's not like B2B doesn't get whacked by bad software or bad actors regulalry. The idea that software updates itself is vastly more benefitial than harmful in the very long term. There so many old machines running outdated software in gated corporate networks, they will get owned immediately once a single one of them is compromised in any way. They are literally trading minor inconveniences for a massive time-bom…

The two sides of your thought are going head to head. "Gated corporate networks" don't benefit from software that "updates itself" (unless we're talking about pure SaaS). It's exactly where auto-updating is completely useless because any company with a functioning IT will go out of its way to not delegate the decisions of when to update or what features are forced in out to the developer and their product manager.

Auto-updates mostly ever practically happen for software used at home or SMB which might not have a functioning IT. If security is the concern why not use auto-updates only for security updates? Why am I gaining features I explicitly did not want, or losing the ones which were the reason I bought the software in the first place? Why does the dev think I am not capable of deciding for myself if or when to update? I have a solid theory of why and it involves an MBA-type person thinking anyone using <$300 software just can't think for themselves and if this line of thought cuts some costs or generates some revenue all the better.

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

#227

Post by oncallthrow »

rustcleaner wrote: post #221
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…

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.

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

#229

Post by RadiozRadioz »

klabb3 wrote: post #222
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…

> 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)

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

#230

Post by Thorrez »

LtWorf wrote: post #135
valenterry wrote: post #119

Earlier quoted context omitted.

Yes it is. Hashes must absolutely be used in that case.

It should just not be done at all. But the main browser vendor loves tracking so they won't forbid this.

Are you saying Chrome should block all script includes that don't have hashes? That'll break tons of sites. See "Don't break the web"[1].

Disclosure: I work at Google, but not on Chrome.

[1] https://flbrack.com/posts/2023-02-15-dont-break-the-web/

Post reply on HN