Comments 17
Андрей, я не C-разработчик, но не могли бы вы пояснить, чтобы злоумышленнику использовать любую из этих т.н. "уязвимостей", что нужно сделать? А то вы сейчас тут приучите народ после каждой строчки кода по 100 проверок добавлять, дабы не породить некую "дыру" в программе.
Про проверки. Да, где-то их может не хватать. Но, например, всё перечисленное здесь возникло не из-за отсутствия проверок, а из-за ошибок в коде.
Что нужно делать? Это целый комплекс мер, который тянет на книгу. Но точно могу сказать, одна из мер, это использование статических анализаторов кода, таких как PVS-Studio. :)
Андрей, спасибо за ответ. Безусловно, это полезный функционал. Могу предложить вам реализовать вам еще один тип ошибок — предупреждения о неэффективном коде. Иногда одна и так команда может быть записана несколько по-разному и в некоторых случаях приводит к лишним вычислениям, инвариантным фрагментам в циклах (например, когда какая-то команда внутри цикла выполняется, но результаты ее выполнения никак не используются или это просто один и тот же вызов). Было бы полезно получать предупреждения о таких потенциально неэффективных местах.
Также могло бы быть полезным выявление дублирования кода в разных модулях.
предупреждения о неэффективном коде
Такие предупреждения уже есть, хотя их пока немного. Мы называем их микро-оптимизации.
Андрей, понимаю вашу специфику (в большей степени поиск ошибок в низкоуровневом коде относительно высокого качества), но может вам замахнуться на всякие Python, Ruby, Java, PHP, Objective C — вот где непаханое поле багов и тормозов :-)
Конечно, понятно, что это будет уже совсем другой продукт. Может и не стоит так распыляться.
Да, это логично. Enterprise все-таки. Переход к языкам с динамической типизацией может потребовать пересмотра всех подходов к анализу.
Основная проблема добавления анализа другого языка — найти экспертов, которые знают, какие там бывают проблемы. Потому что надо сначала самому нарваться несколько раз на ошибку/проблему, чтобы понять, что её стОит выявлять. Желаю удачи в полезном деле! Кстати в качестве вашей рекламы не пробовали получить реальный отзыв от какого-то вашего клиента (не важно платного или бесплатно). Т.е. чтобы не вы сами, а ваши пользователи описали, какой профит они получили от PVS-Studio?
Ну не надо лукавить, здесь, я так понял, вы сами проверили, сами пофиксили и попросили их отписаться.
After publishing every new article about checking some project, people will ask: "Have you reported the bugs to the project authors?" And of course we always do! But this time, we've not only "reported the bugs to the authors" but fixed all those bugs ourselves.
Было бы интереснее услышать тех, кто добровольно сам пользуется и сам фиксит (не команда PVS). Но кто же захочет писать про свои баги. Хотя..
Это смешно звучит для программистов, но для директоров это вот так.
В целом же ничего удивительно. Задача PVS-Studio в том и состоит, чтобы быть лучше компиляторов в плане поиска дефектов.
В первом случае ошибка в юнит-тесте, который проверял меньше, чем следовало. Во втором — ошибка, которая ведёт к снижению производительности через увеличение коллизий хэшкодов, но на корректность не влияет. Доброе дело, да, но вряд ли это прямо fixed vulnerability :-) А уж рекламку вставлять в юнит-тест совсем как-то некрасиво, на мой взгляд. Хватило бы и commit-message.
PVS-Studio: поиск дефектов безопасности