Every Sunday, for years, I’ve been going to my favourite restaurant in downtown Geneva. Always the same table. The same view. Always ordering the same starter, main and dessert. The same wine. Delicious. Un régal. Never been disappointed. Until last weekend. When the owner changed, as did the chef, and the food. A disaster. Fortunately, after the first bites, I noticed. But you won’t.
You won’t today, if you’re a programmer, software developer, VM importer or container administrator. You won’t today, if you run NPM or PyPI. You won’t today, if you import VMs and containers from untrusted sources on the internet. You won’t today, if you copy/paste snippets of code from random origins on the web. You won’t, just as you won’t notice that the owner has changed, that the chef is not the chef anymore.
In fact, it’s the beauty of software engineering to reuse programs/libraries/packages/VMs/containers developed by others. But this comes with a caveat. You need to trust those others. Can you? GitHub, Stack Overflow and others provide zillions of lines of code ready for reuse. And NPM and PyPI make your life easier when it comes to importing, reimporting and updating that code if a new version is available. But that requires trust. Trust that the original owner, the original chef, is honest. Trustworthy, reliable, honourable. With good intentions. Not turning rogue or malicious. Nor turning into a third-party evil attacker.
Packages on NPM, PyPI, GitHub and any other remote-software-provisioning platform have been compromised in the past by accepting backdoored source code into the newest release, by unverified packages and libraries, by compromising the account of the source-code owner or by handing over the maintenance of that source code to a new (evil) maintainer. In 2021, a security researcher executed a successful supply-chain attack against Microsoft, Apple, PayPal, Shopify, Netflix, Tesla, Yelp and Uber simply by publishing public packages using the same name as the company’s internal ones. He took advantage of the fact that PyPI and NPM look out for the newest version and give them priority even over a download from internal sources. So software using NPM or PyPI with internal dependencies on third-party libraries fetches newly released dependencies from the internet, first. All the researcher had to do was to figure out the names of those libraries, publish a more “recent” version and wait for PyPI and NPM to do their job.
So, instead of falling into the same trap, be vigilant. Our development methods do not differ. The risk remains the same for PyPI, NPM or automatic internet downloads. In the interests of integrity and security – but also for better version and revision control, dependency management and licence compliance – we can and must do better. While mitigations exist, like using central software dependency curators, they need to be deployed, centrally managed and curated. The CERN IT department already provides Harbor and Nexus as container and software component repository services, respectively. However, while these are currently non-curated, you should still consider using them in order to avoid direct downloads. Team up with other groups of developers in a joint effort to improve the software you develop, including the packages and libraries you import. And address your needs to your IT representative so that they can make such a centrally managed service possible!
And by the way, what’s your favourite restaurant in Geneva? I need a new one…
_______
Do you want to learn more about computer security incidents and issues at CERN? Follow our Monthly Report. For further information, questions or help, check our website or contact us at Computer.Security@cern.ch.