Polymarket 1h halt after vendor compromise; affected users will be 'made whole'
nbcnews.com
nbcnews.com
My Google account was not compromised. I wouldn't touch Polymarket ever again. There is some kind of massive scam happening here.
Nicholas Carlini has a good talk about the risks on his homepage https://nicholas.carlini.com/ (can't link to the talk directly for some reason)
If you've got a lot of roving bandits with fancy lockpicks, you're village needs to harden the walls, reduce the number of entry points, identify and document entrants more universally, check under more carriages and inside more trunks for stowaways, etc. And with all that comes delays, imprivacy, accusations, false positives.
The low trust world that we're headed towards isn't going to be nearly as fun.
What I mean is, look at how much time and effort we spend on making software services beautiful and branded, and so little time spent on security. In the future we'll probably have fewer webpages and more hardened text-based APIs that end users interact with via their AI agents.
For now most of these appear to be related to supply chain attacks which can be avoided with basic discipline and using features that browsers had for years: https://developer.mozilla.org/en-US/docs/Web/Security/Defens...
If it changes and the hash no longer matches perhaps due customer changing config then the site is faced with the challenge of either the browser refusing to load the script (with potential breakage) or reporting the change which then is probably ignored
It's not really a simple fix for the way the web is built today
If a library serves a script and your site manages user funds you should probably avoid using it or use a cdn that does.
I am not quite sure, but there's also other integrity mechanisms that gurantee that a file was signed by the library developer via a served header with the signature of the file.
Integrity reporting can detect when the script changes
The advice today is the same as it has ever been, though. Always assume that any networked computer is or may become compromised. Do not do anything critical on a networked computer, because it is or may become compromised. You can still use computers, but assume that a bad actor may take control at any time, and plan for that eventuality.
For example, if you are hooking up a networked computer to your town's water supply system, ask yourself "what would happen if Iran got complete control of this system?" If you're putting your school system's students' mental health data into a networked computer, ask yourself "what would happen if all of this data became public?"
Every target is worth attacking, but there are not enough bears to eat everybody. Sure, the bears are breeding, but exponential growth does not look threatening until it suddenly is.
I don't think the "breeding rate" was the limiting factor.
It reminds me of a bit from the book Lying For Money [0], where the author notes that you can often find multiple layers of scams attached to other scams, just like meta-parasite in biology.
[0] https://www.simonandschuster.com/books/Lying-for-Money/Dan-D...
What would happen if America got complete control of this system?
Oh wait. Oops.
This is completely unrealistic advice that 0% of people follow.
https://www.bbc.com/news/articles/c934dq95zpgo
https://duckduckgo.com/?t=fpas&q=public+schools+ransomware&i...
...with a hint of sarcasm, but the percentage is definitely a non-zero number.
It seems like the only “safe” option is a PC (+storage) that never attaches to a network, but that extremely limits its usefulness.
Perhaps a vulnerability still exists (for one offline NAS, only): I use dedicated NICs (on each end) to direct-link my online NAS (which is otherwise local network, only, on a separate NIC), for routine backup.
Perhaps this leaves a bridge-LAN vulnerability?
But one is entirely offline, as are all its clients (dumb TVs, mostly).
Stuff like your town's water, transportation, and medical infrastructure and employee and student data are critical. Your car's drivetrain and safety features are critical. Your home's HVAC can be critical in certain times of year. These things should not be connected to the Internet.
Wired's coverage (25 points) https://news.ycombinator.com/item?id=50296328
WSJ's coverage (20 points) https://news.ycombinator.com/item?id=50294287
Fundamentally: There is no way to lock webapps to reproducible builds.
Except: IPFS could do it but IPFS has been very very poorly maintained.
I published IPFS-boot ~1yr ago and its a simple idea:
1. deploy a webapp bootloader using something immutable like IPFS
2. bootloader is basically react hot reloading except user agrees what to load
3. bootloader polls a mutable list of app updates and user agree or disagree each update
Now the bootloader has a static content addressable URI but it can also do updates. TBH I think IPFS may be a lost cause but something needs to take its place and this idea is transferable to whatever that is. https://github.com/rhodey/IPFS-boot
One could absolutely use subresource integrity to lock one’s reference to a vendor’s subresource to a specific version. That’s what it’s there for.
There is no way to, for instance, only allow updates to a PWA from files signed by an offline key.
How are you going to verify your thousands of dependencies, some of them obfuscated/closed source? And if you can’t, what does integrity buy you?
Of course, that goes against commercial interests.