Comments 26
Блин, ну это, уведомили авторов?
Тьфу, А что так МАЛО?
А проверяли версией под линукс или виндовой?
Вообще, у вас кто-нибудь внутри линуксовую использует, или она только для галочки?
Тьфу, А что так МАЛО?
А проверяли версией под линукс или виндовой?
Вообще, у вас кто-нибудь внутри линуксовую использует, или она только для галочки?
Вообще, у вас кто-нибудь внутри линуксовую использует, или она только для галочки?
И внутри, и снаружи.
Будем рады, если присоединитесь к числу пользователей.
Очень немало, учитывая, что на каждую багу прилагается pull-request с вменяемым исправлением. Много вы пулл-реквестов в оперсорс засабмитили на прошлой неделе? :-)
А проверяли версией под линукс или виндовой?
Даже под FreeBSD.
Сейчас мы можем проверять любые проекты, поэтому просто выбираем удобную платформу для сборки для каждого конкретного проекта.
СиПроВер, пожалуйста, не путайте CWE и CVE, хоть оба списка и ведет одна и таже MITRE, но именно к настоящим проблемам безопасности первый список имеет весьма опосредованное отношение.
Для того, чтобы ошибка в программе стала настоящей проблемой безопасности, она должна быть эксплуатируема, т.е. для нее должно быть найден способ использования в целях, которые ставит перед собой атакующий. И пока такой способ не найден, все эти вышеописанные вещи так и остаются «слабостями», а не проблемами безопасности. Широко известный в узких кругах журнал PoC||GTFO не зря называется именно так. ;)
Если вы действительно хотите помочь пометить серьезные проблемы, связанные с безопасностью, начните предупреждать громче, чем обычно (т.е. с приоритетом 0 вместо 1 и красным цветом) хотя бы о следующих вещах:
Для того, чтобы ошибка в программе стала настоящей проблемой безопасности, она должна быть эксплуатируема, т.е. для нее должно быть найден способ использования в целях, которые ставит перед собой атакующий. И пока такой способ не найден, все эти вышеописанные вещи так и остаются «слабостями», а не проблемами безопасности. Широко известный в узких кругах журнал PoC||GTFO не зря называется именно так. ;)
Если вы действительно хотите помочь пометить серьезные проблемы, связанные с безопасностью, начните предупреждать громче, чем обычно (т.е. с приоритетом 0 вместо 1 и красным цветом) хотя бы о следующих вещах:
- use-after-free, в прямых руках это практически гарантированный WWW с последующии грабежом, убийством и надругательством над гусями
- проблемах с потоком управления (goto fail)
- чтении неинициализированных переменных и областей памяти (Heartbleed/Cloudbleed) и записи за границы массивов (слишком длинный список примеров, чтобы его тут приводить)
В общем, я про то, что лучше добавлять слово «потенциальные» ко всем вашим «дефектам безопасности», пока к каждому из них не написан PoC-эксплоит.
Мне кажется, Вы путаетесь. То, что мы ищем, и есть дефект безопасности (CWE). Ошибка в коде (дефект) может стать причиной уязвимости. Поэтому есть смысл писать «потенциальная уязвимость», что мы и делаем.
Но нет смысла писать «потенциальны дефект» (какой-же он потенциальный, когда вот она ошибка!).
Но нет смысла писать «потенциальны дефект» (какой-же он потенциальный, когда вот она ошибка!).
Вы пишете слово «vulnerability» на своих КДПВ, хотя речь идет о «weakness». Первое — это то, что на русский язык переводится словом «уязвимость», она же немного слабее «security issue», т.е. «проблема безопасности». Второе — это то, что вы переводите как «дефект», а я — как «слабость» или «недостаток». Словосочетание «дефект безопасности», в которое превратилось «weakness» — оно очень странное, и я действительно путаюсь в нем. «Дефект», мне кажется — намного более сильное слово, чем «слабость» или «недостаток», но я могу ошибаться. «Потенциальная проблема безопасности» — вот что такое «weakness», на мой взгляд.
Но останавливаем то мы именно уязвимости. :) Метод — найти и предотвратить их заранее.
Нельзя называть уязвимостью то, что не участвует в атаке. Критерий — наличие PoC, если а PoC нет, это слабое место, недостаток (а не «дефект безопасности», чтобы не значил этот странный термин), что угодно, только не уязвимость.
Я понимаю, что вы хотите сказать, и даже понимаю, зачем именно, но называть любую обнаруженную «weakness» словом «vulnerability» — это буллшит чистой воды, потому что это максимум «potential security issue».
Мужики, у вас отличный продукт без дураков, и хорошая рекламная стратегия (была, по крайней мере) со всеми этими статьями, но не скатывайтесь, прошу вас, в рекламу змеинного масла.
PVS-Studio находит не «уязвимости», а «слабые места в коде, которые могут привести (или не привести) к уязвимости». По настоящему с уязвимостями борятся технологии предотвращения эксплуатации вроде VBS, CFG, RAP, и т.п. Вот слайды с недавнего доклада специалистов из Microsoft о них.
Я понимаю, что вы хотите сказать, и даже понимаю, зачем именно, но называть любую обнаруженную «weakness» словом «vulnerability» — это буллшит чистой воды, потому что это максимум «potential security issue».
Мужики, у вас отличный продукт без дураков, и хорошая рекламная стратегия (была, по крайней мере) со всеми этими статьями, но не скатывайтесь, прошу вас, в рекламу змеинного масла.
PVS-Studio находит не «уязвимости», а «слабые места в коде, которые могут привести (или не привести) к уязвимости». По настоящему с уязвимостями борятся технологии предотвращения эксплуатации вроде VBS, CFG, RAP, и т.п. Вот слайды с недавнего доклада специалистов из Microsoft о них.
Даже если речь идет о «потенциальных» дефектах безопасности, обнаружение таковых при помощи статического анализа в автоматическом режиме на ранних стадиях все же лучше чем ждать пока кто-нибудь напишет PoC-эксплойт, а потом применит этот PoC на практике. ИМХО.
С этим я не спорю, это правильное применение статического анализатора и я тоже применяю его для тех же целей. Спорю я с использованием в рекламных материалах слова «vulnerability», которое слишком сильное в данном случае. Плюс еще с тем, что «дефект безопасности» — это хороший термин для CWE. Дефект, на самом деле, не безопасности, а ПО, и ищет анализатор дефекты/недостатки/изъяны/слабости именно в коде, а не в «безопасности».
Я на одной стороне с разработчиками, но считаю, что продавать статический анализатор с лозунгом «stop vulnerabilities», и использовать это очень сильное слово в статьях и пулл-реквестах — хороший способ создать о себе негативное впечатление продавцов воздуха.
Я на одной стороне с разработчиками, но считаю, что продавать статический анализатор с лозунгом «stop vulnerabilities», и использовать это очень сильное слово в статьях и пулл-реквестах — хороший способ создать о себе негативное впечатление продавцов воздуха.
Я всё понимаю и согласен, но тут уместна фраза: «Скромность красит человека в невзрачный серенький цвет».
Дело в том, что я вижу в разных местах борьбу с уязвимостями и считаю разумным принять участия. Странно говорить про себя скромно, что мы умеем искать жалкие «слабые места в коде, которые могут привести (или не привести) к уязвимости». В то время, как кругом «ищут уязвимости».
В качестве примера, первое что попало под руку:
Дело в том, что я вижу в разных местах борьбу с уязвимостями и считаю разумным принять участия. Странно говорить про себя скромно, что мы умеем искать жалкие «слабые места в коде, которые могут привести (или не привести) к уязвимости». В то время, как кругом «ищут уязвимости».
В качестве примера, первое что попало под руку:
- Этой статьей мы открываем серию публикаций, посвященных обнаружению ошибок и уязвимостей в open-source проектах с помощью статического анализатора кода AppChecker. [1]
- Настоящей статьей мы продолжаем серию обзоров, посвященных обнаружению уязвимостей в open-source проектах с помощью статического анализатора кода AppChecker. [2]
Дело ваше, но эта «война буллшитов» всегда заканчивается одинаково — на рынке не остается нормальных продуктов, т.к. все вообще начинают декларировать 100% защиту от всего, интеграцию со всем, встроенную кофе-машину и кнопку «сделай мне зашибись!». Как с антивирусами сейчас.
Если вы будете писать «мы устранили уязвимости в открытом ПО», не удивляйтесь, что от вас отвернутся и те, кто действительно ищет и устраняет уязвимости, и те, кто разрабатывает открытое ПО. Буллшит рекламный не любит никто, и даже если конкуренты уже вовсю обмазываются им — присоединяться, на мой взгляд, не стоит.
Если вы будете писать «мы устранили уязвимости в открытом ПО», не удивляйтесь, что от вас отвернутся и те, кто действительно ищет и устраняет уязвимости, и те, кто разрабатывает открытое ПО. Буллшит рекламный не любит никто, и даже если конкуренты уже вовсю обмазываются им — присоединяться, на мой взгляд, не стоит.
Гм… Казалось бы, мы и не путаем CWE и CVE и как раз я вчера про это рассуждал в статье "PVS-Studio: поиск дефектов безопасности". И я везде и пишу о потенциальных уязвимостях (они-же дефекты безопасности, т.е. CWE).
Что касается перечисленных вами проблем, то мы их ищем, что не раз демонстрировалось в различных статьях.
Что касается перечисленных вами проблем, то мы их ищем, что не раз демонстрировалось в различных статьях.
А вот можно как-то уточнить определение ошибки V730 (поле класса не инициализировано в конструкторе), чтобы оно не выдавалось для типов, у которых есть конструктор по умолчанию и прописывать его в списке инициализации конструктора не обязательно, т.к. всё равно конструктор вызовется. Просто выдаётся масса этих предупреждений, среди которых могут затеряться те, в которых реально следовало делать инициализацию.
Если честно, не понятна о какой ситуации идёт речь. Есть подозрение, что с кодом всё-таки что-то не так. Прошу привести конкретный синтетический пример, на котором выдаётся ложное срабатывание, и мы обсудим его.
V730 It is possible that not all members of a class are initialized inside the constructor. Consider inspecting: _fileTree, _actorTree
_fileTree и _actorTree это класс, содержащий std::list и объект класса, в котором std::vector. Ни у кого из них вообще конструктор не реализован, используется по умолчанию. Так же там есть булевый флаг, вида: bool _flag = false; Т.е. инициализация по месту объявления, а не в конструкторе. Возможно, что из-за этого объект подозревается в неинициализированности.
Не сразу заметил, что V730 обозначает и точно недоинициализированный объект и тот, который только подозревается в недоинициализированности.
_fileTree и _actorTree это класс, содержащий std::list и объект класса, в котором std::vector. Ни у кого из них вообще конструктор не реализован, используется по умолчанию. Так же там есть булевый флаг, вида: bool _flag = false; Т.е. инициализация по месту объявления, а не в конструкторе. Возможно, что из-за этого объект подозревается в неинициализированности.
Не сразу заметил, что V730 обозначает и точно недоинициализированный объект и тот, который только подозревается в недоинициализированности.
Если честно, не понятна о какой ситуации идёт речь. Есть подозрение, что с кодом всё-таки что-то не так. Прошу привести конкретный синтетический пример, на котором выдаётся ложное срабатывание, и мы обсудим его.
Полюбил PVS-Studio ещё больше, хотя не думал, что такое возможно!
Ещё раз прошерстил интерфейс класса и нашёл отладочно-костыльный флаг, аналогичный тому, про который говорил выше, но не инициализированный. Так что PVS абсолютно правильно подозревал.
Только жаль, что в предупреждении выводились имена объектов, в которых была не инициализированная переменная, а не имя переменной в классе этих объектов, как это происходит с этим же предупреждением, но когда строгая уверенность в недоинициализированности.
Ещё раз прошерстил интерфейс класса и нашёл отладочно-костыльный флаг, аналогичный тому, про который говорил выше, но не инициализированный. Так что PVS абсолютно правильно подозревал.
Только жаль, что в предупреждении выводились имена объектов, в которых была не инициализированная переменная, а не имя переменной в классе этих объектов, как это происходит с этим же предупреждением, но когда строгая уверенность в недоинициализированности.
Sign up to leave a comment.
Дефекты безопасности, которые устранила команда PVS-Studio на этой неделе: выпуск N2