Daniel Ovaska
Feb 25, 2021
  2128
(1 votes)

Security issue with multiple package sources

Scenario

You are using a private nuget feed for a single package v 1.0.0 and a public nuget feed for the rest of your packages. An attacker can then upload a new package to public nuget feed using the same name as your private package but with a higher bug fix version v 1.0.1. Unless you have thought about this scenario your build server will look across all package sources and pick the most updated version (the faked 1.0.1 version on the public feed). So if you are using a private package source you are still not safe unless that is the only source you are using for your packages.

Solution

More detailed information can be found here about this vulnerability (https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-24105) along with suggestions for how to mitigate the risks.

For high security scenarios:

  • Use one feed. If you have a private feed with internal packages, make that the only feed and add secure handling of public packages to that feed if you need. All projects should then use that one safe feed.
    https://azure.microsoft.com/sv-se/services/devops/artifacts/ is a good option that can deliver that if you don't want to create your own.

Additional mitigation:

  • Lock down your versions and make sure your build server can't update minor version automatically.
    Both npm and nuget can generate such a lock file easily that can then be used to force build server to use a specific version of all dependencies. Use nuget restore --lockedmode on CI servers to use the lock file.
  • Make sure one package can only be downloaded from one source.
    Use scope and npmrc file for npm to specify source per package. Use id prefix for nuget packages to block private packages from being uploaded to public feeds.

This is not an Episerver specific vulnerability but good to be aware of if security is important for your site.

I've added it to my security checklist for Episerver solutions, If you haven't gone through that for your site, I would suggest starting at the top and work your way down until you reach a decent level for your security requirements. 

Stay safe, don't get hacked! Happy coding!

Feb 25, 2021

Comments

Please login to comment.
Latest blogs
Opti ID overview

Opti ID allows you to log in once and switch between Optimizely products using Okta, Entra ID, or a local account. You can also manage all your use...

K Khan | Jul 26, 2024

Getting Started with Optimizely SaaS using Next.js Starter App - Extend a component - Part 3

This is the final part of our Optimizely SaaS CMS proof-of-concept (POC) blog series. In this post, we'll dive into extending a component within th...

Raghavendra Murthy | Jul 23, 2024 | Syndicated blog

Optimizely Graph – Faceting with Geta Categories

Overview As Optimizely Graph (and Content Cloud SaaS) makes its global debut, it is known that there are going to be some bugs and quirks. One of t...

Eric Markson | Jul 22, 2024 | Syndicated blog

Integration Bynder (DAM) with Optimizely

Bynder is a comprehensive digital asset management (DAM) platform that enables businesses to efficiently manage, store, organize, and share their...

Sanjay Kumar | Jul 22, 2024

Frontend Hosting for SaaS CMS Solutions

Introduction Now that CMS SaaS Core has gone into general availability, it is a good time to start discussing where to host the head. SaaS Core is...

Minesh Shah (Netcel) | Jul 20, 2024

Optimizely London Dev Meetup 11th July 2024

On 11th July 2024 in London Niteco and Netcel along with Optimizely ran the London Developer meetup. There was an great agenda of talks that we put...

Scott Reed | Jul 19, 2024