Polyfill.io claims reveal new cracks in supply chain, but how deep do they go?

Opinion Libraries. Hushed temples to the civilizing power of knowledge, or launchpads of global destruction? Yep, another word tech has borrowed and debased. Code libraries are essential for adding just the right standard tested functionality to a project. They’re also a natural home for supply chain attacks that materialize malware in the heart of the enterprise like shock troops of Klingons arriving by transporter beam.

Last week saw a beaut. Polyfill.io, which serves 100,000-plus sites with JavaScript enhancements for older browsers, suddenly 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.

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

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.

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

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

READ MORE HERE