Remote code execution, cross-site scripting, and denial of service vulnerabilities account for 2/3 of known vulnerabilities in .NET ecosystem

Welcome to our new security report: .NET open source security insights. This report is split into three posts:

• .NET open source security insights

• Unique to the .NET ecosystem, 75% of the top twenty vulnerabilities have a high severity rating

• Remote code execution, cross-site scripting, and denial of service vulnerabilities account for 2/3 of known vulnerabilities in .NET ecosystem

Our lovely handcrafted pdf report contains all of this information and more in one place, and it's free to download!

What can Snyk tell us about security in the .NET ecosystem?

Now that we have considered the most commonly seen vulnerabilities, let’s take a higher level look at the .NET ecosystem. What types of vulnerabilities are common within the ecosystem? Does the trend of high severity vulnerabilities hold true when we look at the ecosystem as a whole?

Vulnerability types

The following table breaks down the types of vulnerabilities present, for all vulnerabilities with one or more percent share across the .NET ecosystem. It includes the number of distinct vulnerabilities of a given type found in Snyk’s vulnerability database and its percent share.Despite the large variety, just three vulnerability types make up the majority of the vulnerabilities found. Remote code execution (RCE), cross-site scripting (XSS), and denial of service (DoS) vulnerabilities account for 2/3 of .NET vulnerabilities found in Snyk’s vulnerability database.

Remote code execution (RCE), cross-site scripting (XSS), and denial of service (DoS) vulnerabilities account for 2/3 of .NET vulnerabilities found in Snyk’s vulnerability database.

Vulnerability Spotlight

This section is a handy review for anyone wanting more information on the top three vulnerability types in the .NET ecosystem.

Remote code execution

Remote code execution describes a type of vulnerability that occurs when an attacker is able to execute arbitrary commands or code in your application. The code execution can happen over a network and is therefore not tied to any specific geography. Related to this, is command injection security vulnerability.

Cross-site scripting

A cross-site scripting attack occurs when the attacker tricks a legitimate web-based application or site to accept a request as originating from a trusted source. This is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it.

Denial of Service

Denial of service describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users. Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

Known .NET vulnerabilities tend to be high severity

Earlier, when we we considered the top 20 most commonly seen vulnerabilities, we found that the majority were high severity. Does this trend hold true when considering all the .NET vulnerabilities in Snyk’s database? Yes! High severity vulnerabilities account for 70.7% of total. Medium severity vulnerabilities account for the next largest share, at 26.9%. Only 2.4% of .NET vulnerabilities in Snyk’s database are considered low severity.

High severity vulnerabilities account for 70.7% of total. Medium severity vulnerabilities account for the next largest share, at 26.9%.

This may seem to paint a bleak picture of .NET security. That is a large share of high severity vulnerabilities. However, at the time of this writing, every vulnerability found by Snyk in a dependency scan has had a remediation available. Although we cannot be 100% certain as to why this is true, it is possible that this is in part because of the support that the .NET ecosystem receives from Microsoft.

At the time of this writing, every vulnerability found by Snyk in a dependency scan has had a remediation available.

Security spotlight: fixing vulnerabilities

But what does fixing a vulnerability actually entail? This section will give you a quick breakdown of that process.

Upgrade

Once a vulnerability is found, project maintainers will typically include a fix (if possible) in a future version, though the timeline can vary widely. Keeping up to date with release versions is generally a good way to stay on top of security vulnerabilities.Sometimes it is difficult to upgrade a dependency. This can be because dependencies interact with each other and with your code.

Direct vs indirect

Remediating vulnerabilities in direct dependencies is usually straightforward. Upgrade the dependency to the minimum version that includes the fix.Remediating vulnerabilities in indirect dependencies requires two things: a fixed version of the indirect dependency and a version of the direct dependency that utilizes that fixed version.If these two conditions are met, upgrading the associated direct dependency to a version that utilizes the fixed version of the indirect dependency will remediate the issue.If no fix is available at the level of the direct dependency, developers can upgrade the indirect dependency to resolve the issue. However, this has the potential to cause compatibility problems between the dependencies.

Conclusion

In the .NET ecosystem, the number of vulnerabilities per package is low, but the severity of those vulnerabilities tends to be high. This means less time is likely needed to resolve the problems (lower investment) but you are addressing potentially dangerous security problems (high return). In other words, by addressing known vulnerabilities in the .NET packages that you use, you are taking a security step that has a high return on investment.At Snyk, our goal is to help people use open source and stay secure. Part of that goal includes building tools to help people find and automatically fix known vulnerabilities in their dependencies, but identifying and properly disclosing new vulnerabilities is important as well. The .NET ecosystem does not currently have a centralized place to report vulnerabilities in open source libraries. Snyk is a CVE Numbering Authority (CNA), meaning we are able to assign a new vulnerability a CVE number (basically an ID for a vulnerability) and add the vulnerability to relevant databases. As a CNA, Snyk can help you responsibly report vulnerabilities.You can learn more about this process here: https://snyk.io/vulnerability-disclosure.

Thank you!

Thank you for reading our new report on .NET security. We hope you enjoyed it. We want to help you use open source and stay secure, so look for more resources like this from us in the future.Remember, you can download the entire report for free.

Download the paper on .NET open source security insights.