What Is Wrong with Vulnerabilities in C# Projects?

Oct 30 2017

Author: Sergey Vasiliev

The Background (Vulnerabilities in C/C++ Projects)
Vulnerabilities in C# Projects
Conclusion
List of Found Vulnerabilities

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.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 us at the address support@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.