‘Polyfill’ Supply Chain Threat: 4x Worse Than We Thought
Chinese company takes over widely used free web service—almost 400,000 websites at risk.
Last week, we warned you to remove any dependencies on the Polyfill.io web browser fallback service. It’s been taken over by malicious actors and is being used in supply chain attacks, say researchers.
This week brings more research, showing the problem’s almost four times as big as we thought. And major public websites are still using it—including government services.
It’s quite a worry. In today’s SB Blogwatch, we daren’t even breathe on this house of cards.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Chef Boi.
Spackle Attack
What’s the craic? Sead Fadilpašić reports: Polyfill threat seems to be much bigger than initially thought
“Major red flag”
The Polyfill supply chain attack is possibly around three times bigger than previously thought. … Rather than the 100,000 sites previously thought to be hit, new findings from the Censys Research Team claims … 384,773 sites are still linking to the service, [which] is a major red flag.
More detail please? Dan Goodin obliges: Many website admins, it seems, have yet to get memo
“Malicious actions”
For years, the JavaScript code hosted at polyfill[.]com was a legitimate open source project that allowed older browsers to handle advanced functions that weren’t natively supported. By linking to [it], websites could ensure that devices using legacy browsers could render content in newer formats. The free service was popular among websites because all they had to do was embed the link. … The findings underscore the power of supply-chain attacks, which can spread malware to … millions of people simply by infecting a common source.
…
In February, China-based company Funnull acquired the domain and the GitHub account. … On June 25, researchers from security firm Sansec reported that code hosted on the polyfill domain had been changed to redirect users to adult- and gambling-themed websites. … Namecheap suspended the domain. … Content delivery networks such as Cloudflare began automatically replacing pollyfill links with domains leading to safe mirror sites. … uBlock Origin added the domain to its filter list. And Andrew Betts, the original creator of Polyfill, … urged website owners to remove links to the library immediately.
…
[But] one week after malicious behavior came to light, 384,773 sites continued to link to the site … including Hulu, Mercedes-Benz, Warner Bros., … Pearson [and] 182 domains … affiliated with a government entity. … More than 1.6 million sites link[ed] to one or more domains that were registered by the same entity that owns polyfill. At least one … was observed in June 2023 performing malicious actions similar to those of polyfill. That domain, and three others … were also found to have leaked a user’s authentication key for … Cloudflare.
Yikes. What does Funnull have to say for itself? Jeff Burt explains, over on our sister site: Polyfill Becomes a Supply-Chain Risk
“No supply chain risks”
In the months since the acquisition by Funnull, the domain … has been used to deliver malicious code to devices via the websites that embedded the domain, redirecting users to sports betting and pornographic websites … and opening the door to other attacks, such as formjacking, clickjacking and other data theft, according to researchers.
…
[But] the owner … isn’t backing down, … pushing back against the accusations, claiming … media reports were slandering them and that there are no supply chain risks. … They said they’ve secured $50 million in startup funding.
Sounds legit. I am the liquor thinks this type of problem is “Inevitable:”
When you hear a claim like, “We have no supply chain risks,” you know you’re not going to hear anything true. … Given that modern web design is founded on essentially ignoring supply chain risks, problems like this are inevitable. Even my bank’s online banking portal wants to load JavaScript from 5 different domains that are not their own.
…
This does not seem to be a safe way to design web sites. I bet for every example of malicious code on a 3rd-party CDN that becomes public like this one, there are a dozen more that no-one notices because the perpetrators were smarter about it.
Inevitable? O RLY? program_whiz agrees:
Game theory at work? Someone needs to maintain legacy code for free that hosts thousands of sites and gets nothing but trouble … in return. Meanwhile the forces of the world present riches and power in return to turn to the dark side.
…
If security means every maintainer of every OSS package you use has to be scrupulous, tireless, and not screw up for life, not sure what to say when this kind of thing happens other than, “Isn’t that the only possible outcome given the system and incentives on a long enough timeline?” [It’s] a foregone question that was only a matter of “when,” not “if.”
There’s an xkcd for that. It makes u/ProtoJazz pretty uneasy:
I do get pretty uneasy about just how much of the internet relies on the work of a small group of people who for the most part are doing it for free, simply because they like it. … If they suddenly die, or burn out, or just one day decide they’re done or something, it puts … the entire modern world at risk. … It really feels like a fragile system.
But are professionals leeching off of free software? AusPeter draws the obvious conclusion:
Companies like Mercedes should have the resources to run an additional server in order to control their own web stack. It boggles my mind that a bunch of large companies delegate control to other people by not self hosting. I can only imagine that some low level web person linked to this library, closed their ticket, and forgot all about it.
So? What’s the solution, Michael?
Just host everything yourself. I try to ensure that all web products my company develops only contains code we host ourselves. This means I have a cached copy of npmjs, nuget and other packages. It also means that, if these services fail, I’ve a backup and can continue without issue.
…
I have scripts setup to measure API performance and verify that there hasn’t been a change over time. All of these things can be done and lots of them can be automated. However, they require you to design them into the system and stick with it.
BTW, why’s it called Polyfill? Here’s u/balefrost:
I believe the name is inspired by … automotive polyester body filler. Older browsers have gaps, and the polyfill libraries fill in those gaps.
Meanwhile, jacobsenscott can’t understand why this is still a Thing:
Polyfilling and minification both belong on the ash heap of JS development technologies.
And Finally:
Hat tip: Mehitabel_Itrang
You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites—so you don’t have to. Hate mail may be directed to @RiCHi, @richij, @[email protected], @richi.bsky.social or [email protected]. Ask your doctor before reading. Your mileage may vary. Past performance is no guarantee of future results. Do not stare into laser with remaining eye. E&OE. 30.
Image sauce: gnuckx select1 (cc:by; leveled and cropped)
