# Что не так с уязвимостями в C\# проектах?

Эта небольшая заметка является промежуточным итогом на тему поиска уже известных уязвимостей в open source C\# проектах\. Я хотел посмотреть на примеры кода, который бы являлся уязвим и был причиной появления очередной CVE, но оказалось, что не всё так просто\.\.\.

![0537_Vulnerabilities_CS_intermediate_results_ru/image1.png](https://import.viva64.com/docx/blog/0537_Vulnerabilities_CS_intermediate_results_ru/image1.png)

## Предыстория \(уязвимости в C/C\+\+ проектах\)

Я уже сталкивался с подобной задачей касаемо языков программирования C и C\+\+, и хотел бы сделать небольшую отсылку к проделанной ранее работе, чтобы суть вопроса, вынесенного в заголовок, стала более понятна\.

Вдаваться в детали не буду, расскажу в нескольких предложениях\. Предыдущая цель была аналогичной \- посмотреть, какие CVE были обнаружены в open source C/C\+\+ проектах, и выяснить, может ли PVS\-Studio находить подобные проблемы\. По результатам работы я нашёл несколько интересных уязвимостей \(а если бы продолжил работу в этом направлении, уверен, нашёл бы ещё больше\), появления которых можно было бы предотвратить, используя PVS\-Studio\. Эксперимент закончился удачно, и на его основе я написал статью "[Как PVS\-Studio может помочь в поиске уязвимостей?](https://pvs-studio.ru/ru/blog/posts/cpp/0514/)"\.

Удобным было то, что в описании CVE часто фигурировали ссылки на коммиты, закрывающие уязвимость\. Таким образом, просматривая историю изменений кода, можно было понять, в чём заключается уязвимость, и каким образом она была закрыта\. В итоге задача сводилась примерно к тому, чтобы среди таких исправлений найти что\-то интересное\.

Подводя итог вышесказанному, можно выделить несколько пунктов, которые определяют CVE, удобную для проверки:

* Содержит ссылку на исходный код \(до и после исправлений\)\.
* Коммит является локальным, то есть не 'размазан' по нескольким файлам, а затрагивает вполне определённое место\.
* Код в этом месте связан с использованием каких\-то общедоступных средств, а не специфичных для конкретного проекта \(например, каких\-то функций, заменяющих их стандартные аналоги\)\.
* Уязвимость не является следствием специфичной ошибки в логике работы приложения\.

Если CVE отвечает этим требованиям, скорее всего она будет доступна для обнаружения с помощью статического анализа исходного кода\.

## Уязвимости в C\# проектах

В направлении поиска уязвимостей в open source C\# проектах я предпринимал несколько заходов с различных сторон, но все они не принесли ожидаемого результата\.

Основными информационными средствами, на которые я ориентировался, были [база CVE](https://cve.mitre.org/data/downloads/index.html) и сайт [CVE Details](https://www.cvedetails.com/) \(а также Google, GitHub, reddit, Stack Overflow\)\.

Вот основные подходы, которые я использовал:

* Поиск наиболее популярных C\# проектов с GitHub в базе CVE\. C\# проекты на GitHub были отсортированы по количеству 'звёздочек', после чего я 'пробил' по базе CVE порядка 100 проектов \- б_о_льшая их часть даже не упоминается\.
* Была написана небольшая утилита, которая просканировала базу CVE, нашла все ссылки на GitHub \(их оказалось больше 5000\), и 'выцепила' из них те, которые являлись ссылками на коммиты, затрагивающие C\# \(\.cs\) файлы\. На моё удивление, таких ссылок оказалось всего 8\! Этого явно было недостаточно\. Кроме того, не все коммиты подходили под описанные в предыдущем разделе критерии "оптимальности"\.
* Поисковым запросом на GitHub среди issues всех C\# проектов с количеством 'звёзд' больше 10 выбрал те, которые в названии, теме или комментариях содержали слово "CVE"\. Опять мимо \- в большинстве случаев конкретные CVE не рассматривались, либо не было ссылок на коммиты с исправлениями\.
* Перебирал проекты из списка [\.NET Open Source Developer Projects](https://github.com/Microsoft/dotnet/blob/master/dotnet-developer-projects.md)\. Искал их в базе CVE, на сайте CVE Details, в Google\.
* Прошёлся по базе CVE поиском по определённым ключевым словам, вроде C\# или \.Net\.
* Поиск в Google по идентификаторам различных CVE из базы CVE и с сайта CVE Details\.
* Дополнительно искал в Google информацию по различным поисковым запросам, связанным с уязвимостями C\# / \.Net и open source проектами\.

К моему большому удивлению, все эти подходы не принесли ожидаемого результата \- было найдено крошечное количество уязвимостей, в которых были бы также ссылки на исходный код, чтобы можно было точно понять суть проблемы\.

Имея опыт подобной работы с проектами на C/C\+\+ меня вот что удивило:

* Малое количество задокументированных уязвимостей С\# проектов в базе CVE в принципе\. Неужели C\# проекты почти не подвержены уязвимостям? Не очень верится\. Или просто уязвимости в C\# коде не документируются/афишируются, поэтому их так мало в базе CVE?
* Уязвимость есть в базе CVE, есть ссылка на релиз, в котором уязвимость была закрыта \(что само собой уже подтверждает её наличие\), но при этом нет никаких упоминаний уязвимого кода, даже при том, что это open source проект\! Повторюсь, в C/C\+\+ проектах, как правило, были ссылки на конкретные коммиты, закрывающие уязвимости\. Т\.е\. разработчики сообщали не только о том, что уязвимость была закрыта, но и демонстрировали саму проблему и способ её решения\.

## Заключение

В общем, я был удивлён таким положением дел в отношении уязвимостей в C\# проектах\. Почему их так мало? Почему мало примеров уязвимостей, которые были закрыты?

Ситуация действительно такая, какая есть? Или был какой\-то изъян в моих подходах, которые не позволили получить необходимого результата?

Если у вас есть примеры разбора уязвимого кода \(задокументированного, то есть, имеющего идентификатор CVE\) или вы заметили какой\-то явный изъян в моём подходе, не позволивший получить ожидаемых результатов, прошу написать нам на почту – [support@viva64\.com](mailto:support@viva64.com), с интересном прочитаю ваши предложения/замечания\.

## Список найденных уязвимостей

Ниже я привожу список тех уязвимостей, которые бы имели и идентификатор CVE, и примеры уязвимого кода\. Возможно, они будут кому\-то интересны/полезны\. Также, если вы хотите предложить в письме ссылку на пример кода уязвимостей, пожалуйста, посмотрите, не встречается ли идентификатор этой уязвимости в нижеприведённом списке\.

* [CVE\-2017\-15280](https://github.com/umbraco/Umbraco-CMS/commit/5dde2efe0d2b3a47d17439e03acabb7ea2befb64)
* [CVE\-2017\-15279](https://github.com/umbraco/Umbraco-CMS/commit/fe2b86b681455ac975b294652064b2718d4e2ba2)
* [CVE\-2015\-8814](https://github.com/umbraco/Umbraco-CMS/commit/18c3345e47663a358a042652e697b988d6a380eb)
* [CVE\-2015\-8813](https://github.com/umbraco/Umbraco-CMS/commit/924a016ffe7ae7ea6d516c07a7852f0095eddbce)
* [CVE\-2013\-6795](https://github.com/rackerlabs/openstack-guest-agents-windows-xenserver/commit/ef16f88f20254b8083e361f11707da25f8482401)
* [CVE\-2012\-3382](https://github.com/mono/mono/commit/d16d4623edb210635bec3ca3786481b82cde25a2)
* [CVE\-2011\-0991](https://github.com/mono/mono/commit/89d1455a80ef13cddee5d79ec00c06055da3085c)
* [CVE\-2015\-2526](http://blog.malerisch.net/2015/09/net-mvc-redos-denial-of-service-vulnerability-cve-2015-2526.html)
* [CVE\-2016\-0132](https://coding.abel.nu/2016/03/vulnerability-in-net-signedxml/)
* [CVE\-2017\-8759](https://www.fireeye.com/blog/threat-research/2017/09/zero-day-used-to-distribute-finspy.html)