Polyfill supply chain attack hits 100K+ sites • Hacker News Board

Re: Polyfill supply chain attack hits 100K+ sites

#251

Post by aembleton » Wed, Jun 26, 2024, 7:59 AM UTC

lumb63 wrote: post #77

I’ll go ahead and make an assumption that the Chinese government was involved. Countries badly need to figure out a way to punish bad actors in cybersecurity realms. It seems that this type of attack, along with many others, are quickly ramping up. If there isn’t competent policy in this area, it could become very dangerous.

Why would the Chinese government use this to load a gambling website? I'm sure there are many better uses that would be more subtle that they could come up with this opportunity.

Re: Polyfill supply chain attack hits 100K+ sites

#252

Post by aembleton » Wed, Jun 26, 2024, 8:05 AM UTC

acedTrex wrote: post #5

api wrote: post #4

Software supply chains feel like one of the Internet's last remaining high-trust spaces, and I don't think that's going to last long. A tidal wave of this is coming. I'm kind of surprised it's taken this long given how unbelievably soft this underbelly is.

going back to rolling it yourself, or relying on a few high quality stdlib providers that you likely have to pay for.

Paying for dependencies sounds like a good idea. Reduces the incentive to sell out; allows contributors to quit day jobs to focus on fixing bugs and security holes; less likely to result in abandonware.

Re: Polyfill supply chain attack hits 100K+ sites

#253

Post by the8472 » Wed, Jun 26, 2024, 8:31 AM UTC

paranoidrobot wrote: post #221

the8472 wrote: post #88

start projects with Content-Security-Policy: default-src 'self'; then add narrow, individually justified exceptions.

That wouldn't have helped here. Anyone adding CSPs would have had polyfill.io as permitted... which allowed this attack.

The justified in "justified exceptions" is important. Whenever I review CSP additions I ask the following questions

- do we have a trust relationship with the vendor - is it strictly required - what are the alternatives - blast radius

Adding script-src has a pretty high blast-radius. There is no relationship with an unpaid CDN. Alternatives can be vendoring a static polyfill script, or just fixing a few functions manually, depending on desired level of browser support.

So it would not have passed.

Adding an exception for 3rd-party images would have to clear a much lower bar for example but even there GDPR or information leakage could be a concern.

CSP changes are just a great point to stop and think about how the frontend interacts with the rest of the world. If you just rubber-stamp everything then of course it wouldn't have any effect.

Re: Polyfill supply chain attack hits 100K+ sites

#254

Post by robin_reala » Wed, Jun 26, 2024, 8:53 AM UTC

rcarr wrote: post #233

program_whiz wrote: post #14

Game theory at work? Someone needs to maintain legacy code for free that hosts thousands of sites and gets nothing but trouble (pride?) in return. Meanwhile the forces of the world present riches and power in return to turn to the dark side (or maybe just letting your domain lapse and doing something else). If security means every maintainer of every OSS package you use has to be scrupulous, tireless, and not screw u…

I believe tea, the replacement for homebrew, is positioning itself as a solution to this but I rarely see it mentioned here https://tea.xyz/

Tea is not the “replacement for homebrew” apart from the fact that the guy that started homebrew also started tea. There’s a bunch of good reasons not to use tea, not least the fact that it’s heavily associated with cryptocurrency bullshit.

Re: Polyfill supply chain attack hits 100K+ sites

#255

Post by southEastRon » Wed, Jun 26, 2024, 9:10 AM UTC

This was obviously written by a JS beginner (ex: basic mistake on the "missing" function, the author thinks that `this` refers to the function?, same about the `undefined` implicit global assignment..)

Re: Polyfill supply chain attack hits 100K+ sites

#256

Post by mihaic » Wed, Jun 26, 2024, 9:39 AM UTC

cqqxo4zV46cp wrote: post #177

mihaic wrote: post #50

Earlier quoted context omitted.

Sure, but why risk a developer making a typo, saying integrty="sha384-whatever", and that attribute simply being ignored in the html?

“A developer could typo something” is kind of weak because you could use this argument for basically anything.

Why? If you host everything on the same domain there's no possibility of a typo. And, developers could maliciously make a typo that can get past code review, don't you take that into account?

In a lot of situations the system can be designed that a mistake has to be obvious at review for it to even pass the build step. Why not strive for that level of robustness?

Re: Polyfill supply chain attack hits 100K+ sites

#257

Post by m0llusk » Wed, Jun 26, 2024, 9:50 AM UTC

SV_BubbleTime wrote: post #54

m0llusk wrote: post #48

Earlier quoted context omitted.

Alternatively, if you rely on some code then download a specific version and check it before using it. Report any problems found. This makes usage robust and supports open source support and development.

I guess that would work if new exploits weren’t created or discovered. Otherwise all your plan to “run old software” is questionable.

That isn't the plan. For this to work new versions have to be aggressively adopted. This is about accepting that using an open source project means adopting that code. If you had an internal library with bug fixes available then the right thing is to review those fixes and merge them into the development stream. It is the same with open source code you are using. If you care to continue using it then you need to get the latest and review code changes. This is not using old code, this is taking the steps needed to continue using code.

Re: Polyfill supply chain attack hits 100K+ sites

#258

Post by adonisk » Wed, Jun 26, 2024, 9:50 AM UTC

karaterobot wrote: post #22

It's amazing to me that anyone who tried to go to a website, then was redirected to an online sports betting site instead of the site they wanted to go to, would be like "hmm, better do some sports gambling instead, and hey this looks like just the website for me". This sort of thing must work on some percentage of people, but it's disappointing how much of a rube you'd have to be to fall for it.

It could be targeting people that already have such a website's tab open somewhere in the browser.

Assuming the user opened the website and didn't notice the redirect (this is more common in mobile), then forgot about it and when they opened their browser again a few days later, their favorite gambling website was waiting for them, and proceeded to gamble as they usually do.

Re: Polyfill supply chain attack hits 100K+ sites

#259

Post by SV_BubbleTime » Wed, Jun 26, 2024, 10:02 AM UTC

chubs wrote: post #238

SV_BubbleTime wrote: post #53

Earlier quoted context omitted.

Real solution? We’re in a complexity crisis and almost no one sees it. It’s not just software dependencies of course. It’s everything almost everywhere. No joke, the Amish have a point. They were just a few hundred years too early.

I 100% agree. I feel a huge part of my responsibility as a software "engineer" is to manage complexity. But i feel i'm fighting a losing battle, most everyone seems to pull in the opposite direction. Complexity increases your surface area for bugs to hide in. I've come to the conclusion it's tragedy-of-the-commons incentives: People get promotions for complex and clever work, so they do it, at the cost of a more-comp…

Right, no one is incentivizing simple solutions. Or making sure that the new smart system just cannot be messed up.

We need thinner faster lighter leaner on everything… because IDK why, MBAs have decided that reliability will just not sell.

Re: Polyfill supply chain attack hits 100K+ sites

#260

Post by trekz » Wed, Jun 26, 2024, 10:31 AM UTC

program_whiz wrote: post #43

program_whiz wrote: post #14

Game theory at work? Someone needs to maintain legacy code for free that hosts thousands of sites and gets nothing but trouble (pride?) in return. Meanwhile the forces of the world present riches and power in return to turn to the dark side (or maybe just letting your domain lapse and doing something else). If security means every maintainer of every OSS package you use has to be scrupulous, tireless, and not screw u…

in a strange way, this almost makes the behavior of hopping onto every new framework rational. The older and less relevant the framework, the more the owner's starry-eyed enthusiasm wears off. The hope that bigcorp will pay $X million for the work starts to fade. The tedium of bug fixes and maintenance wears on, the game theory takes it's toll. The only rational choice for library users is to jump ship once the numbe…

> in a strange way, this almost makes the behavior of hopping onto every new framework rational.

Or maybe not doing that and just using native browser APIs? Many of these frameworks are overkill and having so many "new" ones just makes the situation worse.