Для получения триального ключа
заполните форму ниже
Team License (базовая версия)
Enterprise License (расширенная версия)
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Бесплатная лицензия PVS-Studio для специалистов Microsoft MVP
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Мне интересно попробовать плагин на:
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

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

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

30 Окт 2017

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

0537_Vulnerabilities_CS_intermediate_results_ru/image1.png

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

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

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

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

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

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

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

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

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

Основными информационными средствами, на которые я ориентировался, были база CVE и сайт CVE Details (а также 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. Искал их в базе 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) или вы заметили какой-то явный изъян в моём подходе, не позволивший получить ожидаемых результатов, прошу написать мне на почту - vasiliev@viva64.com, с интересном прочитаю ваши предложения/замечания.

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

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

Популярные статьи по теме
Атака Trojan Source: скрытые уязвимости

Дата: 15 Апр 2022

Автор: Гость

Мы представляем новый тип атаки для внедрения в исходный код вредоносных изменений, по-разному выглядящих для компилятора и человека. Такая атака эксплуатирует тонкости стандартов кодирования символо…
Почему моё приложение при открытии SVG-файла отправляет сетевые запросы?

Дата: 18 Фев 2022

Автор: Сергей Васильев

Вы решили сделать приложение, работающее с SVG. Набрали библиотек, запаслись энтузиазмом, и в итоге всё удалось. Но вот незадача! Внезапно вы обнаруживаете, что приложение отправляет странные сетевые…
Уязвимости из-за обработки XML-файлов: XXE в C# приложениях в теории и на практике

Дата: 11 Фев 2022

Автор: Сергей Васильев

Как простая обработка XML-файлов может стать дефектом безопасности? Каким образом блог, развёрнутый на вашей машине, может стать причиной утечки данных? Сегодня мы ответим на эти вопросы и разберём, …
OWASP Top Ten и Software Composition Analysis (SCA)

Дата: 22 Окт 2021

Автор: Никита Липилин

Категория A9 из OWASP Top Ten 2017 (ставшая A6 в OWASP Top Ten 2021) посвящена использованию компонентов с известными уязвимостями. Для её покрытия в PVS-Studio разработчикам придётся превратить анал…
Как Visual Studio 2022 съела 100 Гб памяти и при чём здесь XML бомбы?

Дата: 07 Сен 2021

Автор: Сергей Васильев

В апреле 2021 года Microsoft анонсировала новую версию своей IDE – Visual Studio 2022, попутно объявив, что она будет 64-битной. Сколько мы этого ждали — больше никаких ограничений по памяти в 4 Гб! …

Комментарии (0)

Следующие комментарии
Этот сайт использует куки и другие технологии, чтобы предоставить вам более персонализированный опыт. Продолжая просмотр страниц нашего веб-сайта, вы принимаете условия использования этих файлов. Если вы не хотите, чтобы ваши данные обрабатывались, пожалуйста, покиньте данный сайт. Подробнее →
Принять