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

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

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

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

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

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

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


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

>
>
>
1000 глаз, которые не хотят проверять к…

1000 глаз, которые не хотят проверять код открытых проектов

17 Дек 2021

Есть такой миф, что открытое программное обеспечение более качественное и безопасное, чем закрытое. Много раз это обоснованно ставилось под сомнение. Существует примеры, когда в открытом коде находили эпичные уязвимости, которые скрывались от разработчиков и пользователей долгие годы. Я считаю, что качество проекта зависит от того, как руководители разработки построили процесс и какие методологии/инструменты используются, а не от того, открыт или закрыт проект.

0900_1000_eyes_ru/image1.png

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

Как разработчик PVS-Studio, нашедший несколько тысяч ошибок в открытых проектах, я очень скептически к этому отношусь. Во-первых, я сомневаюсь, что так уж часто кто-то из этих абстрактных сторонних людей на самом деле ищет ошибки и уязвимости. Во-вторых, будучи как раз этим редким человеком, я могу утверждать, что разработчикам часто до балды эти старания. То есть самим разработчикам может быть неинтересно качество и надёжность их проектов. Им интересны новые фичи или что-то ещё, а не потенциальные проблемы и дефекты безопасности.

Множество раз мои сообщения про найденные ошибки игнорировались или откладывались в дальний ящик авторами открытых проектов. Хочется proof'ов? Пожалуйста. Сегодня у меня как раз есть красивый жирный пример.

Меня cподвигло написать эту мини-заметку неожиданное письмо от багтрекера проекта Samba. Я сначала даже не понял, что это за письмо такое. Оказывается, добрались до ошибок, отписанных мной ещё 9 лет назад! Bug 9320 — PVS-Studio.

0900_1000_eyes_ru/image3.png

Девять лет всем всё равно, что в проекте баги. Девять лет всем всё равно, что в проекте присутствуют старые версии библиотек с потенциальными уязвимостями типа CWE-14. Да, собственно, и сейчас, пока я пишу эти строки, в коде присутствуют всё те же опасные вызовы memset. Например, здесь:

static void
md_result(MD_CTX * ctx, unsigned char *dst)
{
  SHA256_CTX tmp;

  memcpy(&tmp, ctx, sizeof(*ctx));
  SHA256_Final(dst, &tmp);
  memset(&tmp, 0, sizeof(tmp));
}

Или здесь:

static void
calc(struct md2 *m, const void *v)
{
  unsigned char x[48], L;
  const unsigned char *p = v;
  int i, j, t;

  ....
  memcpy(m->state, x, 16);
  memset(x, 0, sizeof(x));
}

Вызовы этих memset компилятор удалит, и приватные данные будут продолжать находиться в памяти. Если вы далеки от этой темы, то разобраться, что к чему, поможет статья "Безопасная очистка приватных данных".

Возможно, конкретно эти баги и дефекты безопасности никакой реальной беды и угрозы не представляют. Дело в другом. Разработчикам проекта всё равно. И сторонним разработчикам всё равно. Никто не берёт и не исправляет хотя бы те баги, которые можно взять и найти с помощью PVS-Studio. И даже уже найденные баги не торопятся исправлять.

Бомбанул. Стало полегче. Спасибо, кто выслушал :). Буду ссылаться на эту заметку, когда кто-то вновь заведёт шарманку на тему того, что открытый код безопаснее.

Популярные статьи по теме
Holy C++

Дата: 23 Ноя 2022

Автор: Гость

В этой статье постараюсь затронуть все вещи, которые можно без зазрения совести выкинуть из С++, не потеряв ничего (кроме боли), уменьшить стандарт, нагрузку на создателей компиляторов, студентов, из…
Продление жизни временных значений в С++: рецепты и подводные камни

Дата: 01 Ноя 2022

Автор: Гость

Прочитав эту статью, вы узнаете следующее: способы, которыми можно продлить время жизни временного объекта в С++; рекомендации и подводные камни этого механизма, с которыми может столкнуться С++ прог…
Как мы баг в PVS-Studio искали или 278 Гигабайтов логов

Дата: 28 Окт 2022

Автор: Григорий Семенчев, Сергей Ларин, Филипп Хандельянц

Предлагаем вашему вниманию интересную историю о поиске бага внутри анализатора PVS-Studio. Да, мы тоже допускаем ошибки, но мы готовы засучить рукава и залезть в самую глубину "кроличьей норы".
0, 1, 2, Фредди забрал Blender

Дата: 26 Окт 2022

Автор: Андрей Карпов

Эта статья могла бы получить название "Как PVS-Studio защищает от поспешных правок кода, пример N7". Однако так именовать статьи становится скучновато. Поэтому сейчас вы узнаете, причём здесь Фредди …
Примеры ошибок, которые может обнаружить PVS-Studio в коде LLVM 15.0

Дата: 25 Окт 2022

Автор: Андрей Карпов

Компиляторы развиваются и выдают всё больше предупреждений. Остаются ли преимущества от использования статических анализаторов кода, таких как PVS-Studio? Да, так как анализаторы тоже развиваются. Пе…

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

Следующие комментарии
Unicorn with delicious cookie
Мы используем куки, чтобы пользоваться сайтом было удобно.
Хорошо