To get a trial key
fill out the form below
Team License (a basic version)
Enterprise License (an extended version)
* By clicking this button you agree to our Privacy Policy statement

Request our prices
New License
License Renewal
--Select currency--
USD
EUR
RUB
* By clicking this button you agree to our Privacy Policy statement

Free PVS-Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

Message submitted.

Your message has been sent. We will email you at


If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

>
>
>
What Is Wrong with Vulnerabilities in C…

What Is Wrong with Vulnerabilities in C# Projects?

Oct 30 2017

This small article is an intermediate result of a search on a topic of already known vulnerabilities in open source C# projects. I wanted to look at the examples of code that was vulnerable, which has been the cause of a regular CVE appearing, but it turned out that it was not that easy...

0537_Vulnerabilities_CS_intermediate_results/image1-69c8aedf7d43e499da6ce219f64e9f9f.png

The Background (Vulnerabilities in C/C++ Projects)

I have already faced a similar issue regarding the C and C++ programming languages, and I would like to make a small reference to previous work, so that the question of the matter rendered in title, became more understandable.

I will not go into detail, I will just give a description in a few sentences. A previous aim was similar - to see which CVE were found in open source C/C++ projects and find out if PVS-Studio was able to find such problems. According to the results of the work, I found several interesting vulnerabilities (if I continued working in that direction, I'm sure, I would find even more), which could have been prevented in case of using PVS-Studio. The experiment ended successfully, and, on this basis, I wrote an article "How Can PVS-Studio Help in the Detection of Vulnerabilities?".

A convenient advantage was that in the CVE description the references to commits, closing a vulnerability, were often included. Thus, looking through the history of code changes, you could understand what was the vulnerability, and the way it was closed. As a result, the issue was about finding something interesting among these corrections.

In summary, there are several points that make the CVE outstanding as convenient for a check:

  • Contains a link to the source code (before and after corrections).
  • Commit contains corrections of a small fragment of code in a single file.
  • The code in this fragment is related to the use of some standard features, such as functions, libraries, and so on, rather than to some specific features for a particular project (for example, for some functions that replace their standard analogs).
  • The vulnerability is not the result of a specific error in the logic of the application work.

If CVE meets these requirements, most likely it will be available for detection using static analysis of the source code.

Vulnerabilities in C# Projects

I had made several tries from different sides towards finding vulnerabilities in open source C# projects, but they all have not produced the expected outcome.

The major information resources at which I was aiming, were the CVE base and the CVE Details site (as well as Google, GitHub, reddit, Stack Overflow).

Here are the basic approaches that I have used:

  • Search of the most popular C# projects from GitHub in CVE database. C# projects on GitHub have been sorted by the ratings, after that I run through the CVE database about 100 projects, most of them were not even mentioned.
  • A small utility was written which has scanned the CVE base, found all the links on GitHub (more 5000), and selected those which constituted the references to the commits that affected the C# (.cs) files. To my surprise, there were only 8 links! This definitely was not enough. In addition, not all the commits were coming under the 'optimal' criteria, described in the previous section.
  • Among all of the C# projects' issues with a rate more than 10, I chose the ones, which contained "CVE" in a heading, subject or comments. Off-target again - in most cases the specific CVE have not been considered or there were no references to commits with corrections.
  • I also looked through the projects from the .NET Open Source Developer Projects list. I was looking for them in the CVE base, on the CVE Details website, in Google.
  • I looked through the CVE base, searching by specific keywords, such as C# or .Net.
  • I also searched in Google by various identifiers of CVE from CVE database and from the CVE Details web site.
  • In addition, I searched in Google information by various search requests, related to C# / .Net vulnerabilities and open source projects.

To my great surprise, none of these approaches has yielded the desired result, as a tiny number of vulnerabilities was found, which had links to the source code, so that you could accurately understand the point of the problem.

Having experience of working with such projects on C/C++, I was really surprised by a small number of documented vulnerabilities of C# projects in CVE database at all.

  • Is it really true that the C# projects are practically not exposed to vulnerabilities? Too good to be true. May be the vulnerabilities in C# code are just not documented/highlighted, so there are so few of them in the CVE base.
  • The vulnerability is in CVE database, there is a link to the release in which the vulnerability was closed (which itself confirms its existence), but there is no mention of the vulnerable code, even though it's an open source project! Again, generally, in C/C++ projects, there were references to specific commits, closing vulnerabilities. Which means, that developers reported not only that vulnerability was closed, but also demonstrated the problem and its solution method.

Conclusion

In general, I was surprised with this situation regarding vulnerabilities in C# projects. Why so few of them? Why are there few examples of vulnerabilities that have been closed?

Is the situation actually as it is? Or was there some flaw in my approaches, which did not let me get the desired result?

If you have examples of vulnerable code (documented, i.e. which has a CVE identifier) or you noticed some apparent flaw in my approach, not allowing obtaining the expected results, please, email me at the address vasiliev@viva64.com, I will read your suggestions/comments with a great interest.

List of Found Vulnerabilities

Below I would like to give a list of vulnerabilities that had both the CVE identifier, and examples of vulnerable code. Perhaps, they will be interesting/useful for someone. Also, if you would like to offer a link on an example of code vulnerabilities in a email, please, make sure that the identifier is not in the following list.

Popular related articles
Trojan Source: Invisible Vulnerabilities

Date: Apr 15 2022

Author: Guest

We present a new type of attack in which source code is maliciously encoded so that it appears different to a compiler and to the human eye. This attack exploits subtleties in text-encoding standards…
Why does my app send network requests when I open an SVG file?

Date: Feb 18 2022

Author: Sergey Vasiliev

You decided to make an app that works with SVG. Encouraged by the enthusiasm, you collected libraries and successfully made the application. But suddenly you find that the app is sending strange netw…
Vulnerabilities due to XML files processing: XXE in C# applications in theory and in practice

Date: Feb 11 2022

Author: Sergey Vasiliev

How can simple XML files processing turn into a security weakness? How can a blog deployed on your machine cause a data leak? Today we'll find answers to these questions, learn what XXE is and how it…
OWASP Top Ten and Software Composition Analysis (SCA)

Date: Oct 22 2021

Author: Nikita Lipilin

The OWASP Top Ten 2017 category A9 (which became A6 in OWASP Top Ten 2021) is dedicated to using components with known vulnerabilities. To cover this category in PVS-Studio, developers have to turn t…
How Visual Studio 2022 ate up 100 GB of memory and what XML bombs had to do with it

Date: Sep 07 2021

Author: Sergey Vasiliev

In April 2021 Microsoft announced a new version of its IDE – Visual Studio 2022 – while also announcing that the IDE would be 64-bit. We've been waiting for this for so long – no more 4 GB memory lim…

Comments (0)

Next comments
This website uses cookies and other technology to provide you a more personalized experience. By continuing the view of our web-pages you accept the terms of using these files. If you don't want your personal data to be processed, please, leave this site.
Learn More →
Accept