Poyfill.io claims reveal new cracks in supply chain, but how deep do they go?
- Reference: 1719829928
- News link: https://www.theregister.co.uk/2024/07/01/poyfillio_comment/
- Source link:
Last week saw a beaut. Polyfill.io, which serves 100,000-plus sites with JavaScript enhancements for older browsers, suddenly [1]stood accused of poisoning its functions with malware and thus attacking all of those sites' users. It wasn't even believed to be the standard supply chain hack, where the bad guys get into an unsuspecting middleware peddler and plant the pathogens. The claimed chain was that polyfill.io had been bought earlier this year and the new owners were themselves responsible. The call's gone out to stop using polyfill.io immediately, with content delivery network Cloudflare redirecting calls to the site to sanitized proxies.
Polyfill.io's first reaction was to accuse the media and Cloudflare of slander. Perhaps a better position to take would have been to profess innocence, say you're taking the situation seriously, and that you're working closely with Cloudflare to urgently understand the matter. Angry accusations of media conspiracy may be very 2020s, but they put you in questionable company. In any case, the very concept of supply chain attacks by the owners of a supplier is a special case that deserves inspection, one that will need its own rules of engagement to control. It's just that, right now, those rules are hard to discern.
[2]
There's nothing new in companies buying an established software product and then filling it full of cack, as the allegation against Polyfill.io goes. In the days when closed source shareware from centralized repositories were the PC nerd's go-to playpen – no, Steve Jobs did not invent the app store – familiar favorites could go bad overnight. Nullsoft's WinAmp MP3 player app got sold to AOL, and promptly started installing the AOL desktop software by default. A popular product with intimate access to user systems will always be a tempting target, and middleware is emphatically on the list. While the [3]worst excesses of turn-of-the-century PC app repositories have been largely, but not totally, curbed by the modern app store, no such curated protection exists for the enterprise.
[4]
[5]
There's also nothing new in having functionality dynamically served by a third party. Tim Berners-Lee's original WWW spec was all about seamlessly mixing multiple independent servers on a single page. In those idealistic days, the fact that this moved the responsibility for knowing what to trust from the user to the website owner didn't seem to matter. In these days of ad tech, trackers, and covert data mining, it matters a hell of a lot. That responsibility most definitely includes third-party JavaScript served live from elsewhere, especially if you chose to use it.
It's also a double hostage to fortune. A supply chain attack on a library package you compile with your code is nasty enough, but you can go back to the last good version and be back on air with a degree of nimbleness. If your library lives in the dungeons of a third party gone bad, not only are they unlikely to offer a regression to safety, you couldn't possibly trust them if they did. That may take some fixing. Cloudflare's diversion of polyfill.io calls to a safe place is a godsend, but gods are capricious, not a strategy to rely on. Plus, if the original problem didn't start with polyfill.io after all, the legality of hijacking its traffic may be hard to defend. Not everyone with the chance to do so may be bold enough.
[6]Meta, Microsoft SQL Server make strange bedfellows on a couch of cyber-pain
[7]Can platform-wide AI ever fit into enterprise security?
[8]Fragile Agile development model is a symptom, not a source, of project failure
[9]Broadcom's VMware strategy looks ever more shaky - and less relevant
The final special aspect of this incident is the tyranny of metrics – or, to be more wholesome, the urge towards inclusivity. The polyfill.io product is popular because it enables provision of services for older browsers that lack modern features. Those users will get a good experience, while you get to produce a modern site without the Sisyphean slog of maintaining special access for those who can't or won't get with the program. The unspoken aspect of this is that you've not just created a new attack vector for all users, regardless of how à la mode their browsers are. You've tacitly encouraged the holdouts to carry on traipsing the web with vulnerable, unpatched code on their systems. Was that in your product security equation? It is now.
Responsibility is, alas, as much fun as making out with a cactus. When it comes to user security, that's a [10]saguaro . Everyone wants a fit and forget, do this and you'll be OK with a fix that absolves us, but security doesn't work that way. It especially doesn't work that way if a previously trusted component supplier goes rogue. There won't be a single answer, given the realities of our machinery of connection. In the same way as curated app stores got rid of most of the anarchy, and digital certificates kept most of the trust and freedom online, mitigations will evolve. Perhaps.
[11]
Until that day, even after, there's one state of mind that will help more than anything. When something goes wrong in something you've helped create, even as a result of malfeasance on the other side of the world, take a bit of ownership. Ask yourself whether you'd have done anything differently if you knew then what you know now. Everyone who builds code that connects outward to our wired humanity has that little chip of responsibility towards it all. It may not be in your job spec, it may not come up in conversation, but it deserves to be part of your mental toolkit. Unlike an abducted library, it will always serve you well. ®
Get our [12]Tech Resources
[1] https://www.theregister.com/2024/06/25/polyfillio_china_crisis/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZoLSp4TlyQ@Dkl@jj4WI3gAAAIw&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://www.theregister.com/2024/06/23/google_chrome_web_store_vetting/
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZoLSp4TlyQ@Dkl@jj4WI3gAAAIw&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZoLSp4TlyQ@Dkl@jj4WI3gAAAIw&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://www.theregister.com/2024/06/24/meta_ms_sql_column/
[7] https://www.theregister.com/2024/06/17/opinion_platformwide_ai_security/
[8] https://www.theregister.com/2024/06/10/agile_opinion_column/
[9] https://www.theregister.com/2024/06/03/broadcoms_vmware_strategy_looks_ever/
[10] https://en.wikipedia.org/wiki/Saguaro
[11] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZoLSp4TlyQ@Dkl@jj4WI3gAAAIw&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[12] https://whitepapers.theregister.com/
The solution is, was, and always will be that website owners serve known good libraries themselves and update them themselves. This is at odds with the tracking industrial complex that the modern web has become and also makes websites more expensive to maintain, so it won't happen.
Also, 3rd party resources are suspect data-protection-wise: the 3rd party gets the user's ip-address and the URL of the referring page (at least).
There is even a German court decision against this: https://www.theregister.com/2022/01/31/website_fine_google_fonts_gdpr/
In a nutshell: since a resource can be hosted locally it is not necessary to hand information about a visiting user to a 3rd party and therefore this isn't lawful in the sense of the GDPR Article 6(1), where all subsections (b-f) begin with 'processing is *necessary* for ...' (except the subsection for consent (a), which wouldn't be valid if made a requirement for using a site (Article 4(11), Article 7(4)). (https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R0679)
just host everything yourself
I try to ensure that all web products my company develop only contains code we host ourselves. This means I have a cached copy of npmjs, nuget and other packages. It also means that these services fail I've a backup and can continue without issue.
I host fonts,scripts images etc for all sites on our servers. 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. It also generally means that you marketing team aren't going to get everything that they want.
Our company website however is the antithesis of this approach.
> familiar favorites[sic] could go bad overnight. Nullsoft's WinAmp MP3 player app got sold to AOL, and promptly started installing the AOL desktop software by default.
There was me thinking that targeting hospitals with ransomeware was bad...
Not the browser I'm coding for? Just call it a security risk.
> You've tacitly encouraged the holdouts to carry on traipsing the web with vulnerable, unpatched code on their systems
Or they are using a fully up to date, fully patched browser - which happens not to be the one you've decided is The One, so it doesn't pander to whatever excess flummery you've decided to put onto your website.
Which is best for your site clients, to use whatever featurettes your browser is trying out this month, or sticking to the functions that have passed the test of time, been accepted industry-wide and implemented by all the players (or locally stubbed-out 'cos they aren't of use to a text-only browser but the useul bits of the page still work)?
Re: Not the browser I'm coding for? Just call it a security risk.
" a text-only browser "
I think there are FAR to many people being paid to create websites that do not even know that such a thing is possible, never mind exists.
Re: Not the browser I'm coding for? Just call it a security risk.
Which could (well should) get them a slap as these can be used by disabled people for things like screenreaders
Please fix your Headline !!!
Poy <---> Poly
:)
Actually needed?
Yeah, it serves code to let older browsers use "modern" (whatever that means) websites.
Except: Most modern websites are kind of... let's not be shy: shite - to navigate, search for stuff, bookmark (remember) stuff, slow to load (hello, 3rd and 5th party content), unwanted features (like zooming a picture on mouseover). They are really bad to navigate on a non-mobile, landscape oriented device, because that actually useful "look at the screen aspect ratio and reflow stuff accordingly" feature is not used, and websites serve you a massive, screen-filling, full width full height picture of something irrelevant for you (I'm looking at most university websites I have visited in the past, or news websites that shwo you only the single headline).
It seems there are no web developers any more, no people caring about actual usability, no concern about performance, load times.
Yeah, I'm old. And bitter. So?