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

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

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

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

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

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

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


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

>
>
>
Потенциальная уязвимость

Потенциальная уязвимость

03 Июн 2021

Потенциальная уязвимость (security weakness) — это ошибка в программном коде, которая при определённом стечении обстоятельств может быть использована злоумышленником для влияния на процесс работы в программе. Если способ использования программной ошибки найден, то это уже настоящая уязвимость (vulnerability).

Терминология

Программная ошибка. Ошибка в коде может как явно проявлять себя в виде некорректной работы программы, так и оставаться незаметной. При этом некоторые "спящие" ошибки можно эксплуатировать, и тогда можно говорить, что это уязвимость. Именно обыкновенные программные ошибки, а не высокоуровневые просчёты в системах безопасности чаще всего приводят к появлению уязвимостей.

The National Institute of Standards and Technology (NIST) reports that 64% of software vulnerabilities stem from programming errors and not a lack of security features.

Потенциальная уязвимость. Ошибка в коде, которую теоретически можно использовать и создать эксплойт. Другие названия: дефект безопасности, security weakness. Существует система классификации ошибок, приводящих к уязвимостям: Common Weakness Enumeration (CWE). Таким образом, если найденная ошибка в коде может быть классифицирована согласно CWE, то перед нами потенциальная уязвимость.

Уязвимость. Ошибка, про которую уже стало известно, что её можно использовать во вредоносных целях. Такие ошибки собираются в базу данных общеизвестных уязвимостей информационной безопасности: Common Vulnerabilities and Exposures (CVE).

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

SAST (Static Application Security Testing). Статические анализаторы, которые ориентированы на поиск ошибок, связанных с безопасностью. При этом реализуются два разных подхода, про которые будет рассказано ниже.

Различие между потенциальной уязвимостью и уязвимостью

Во многих статьях и документации к статическим анализаторам кода часто смешиваются понятия потенциальная уязвимость и уязвимость. Делается это или по причине недостаточной компетентности авторов публикаций, или для того, чтобы сделать описание проблем более пугающим.

Например, можно встретить текст такого типа:

Статический анализатор нашёл уязвимость, так как здесь может произойти переполнение буфера...

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

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

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

Примечание. Если вы используете PVS-Studio как плагин для SonarQube, то часть предупреждений будет попадать в раздел "Уязвимости". На самом деле это, конечно не уязвимости, а потенциальные уязвимости. Просто разработчики SonarQube решили назвать серьёзные дефекты сразу уязвимостями.

Мы разобрали, почему не стоит каждую ошибку сразу именовать уязвимостью. Однако это не значит, что наличие таких ошибок в приложении допустимо. Нет смысла думать, исправлять ту или иную потенциальную уязвимость или нет. Любую проблему в коде лучше сразу исправить. Это предотвратит ненулевую вероятность, что кто-то придумает, как можно эксплуатировать ту или иную ошибку, и тем самым откроет новую уязвимость (т.е. появится уязвимость 0-ого дня).

Пример потенциальной уязвимости

Ошибка "недостижимый код" описана в базе CWE как CWE-561, а значит, является потенциальной уязвимостью. Давайте посмотрим, каким образом такая потенциальная уязвимость может оказаться как безобидной с точки зрения безопасности ошибкой, так и серьезной уязвимостью.

Вначале рассмотрим фрагмент кода из игры Vangers: One For The Road (подробности).

void uvsVanger::break_harvest(void){
  ....

  pg = Pworld -> escT[0] -> Pbunch 
    -> cycleTable[Pworld -> escT[0] -> Pbunch -> currentStage].Pgame;

  if (!pg) {
    return;
    ErrH.Abort("uvsVanger::break_harvest : don't know where to go ");
  }
  
  ....
}

Предупреждение PVS-Studio: V779 CWE-561 Unreachable code detected. It is possible that an error is present.

В случае некоего ошибочного состояния программы функция break_harvest должна записать сообщение в лог и завершить свою работу. Случайно операция записи в лог расположена в коде уже после оператора return. То, что в лог не попадёт отладочное предупреждение, неприятно и однозначно является ошибкой, которую следует исправить. Однако никак нельзя сказать, что эта ошибка является уязвимостью.

Теперь рассмотрим ошибку, которая стала причиной появления уязвимости в операционной системе iOS.

Описание уязвимости CVE-2014-1266: The SSLVerifySignedServerKeyExchange function in libsecurity_ssl/lib/sslKeyExchange.c in the Secure Transport feature in the Data Security component in Apple iOS 6.x before 6.1.6 and 7.x before 7.0.6, Apple TV 6.x before 6.0.2, and Apple OS X 10.9.x before 10.9.2 does not check the signature in a TLS Server Key Exchange message, which allows man-in-the-middle attackers to spoof SSL servers by using an arbitrary private key for the signing step or omitting the signing step.

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, 
                                 bool isRsa, 
                                 SSLBuffer signedParams,
                                 uint8_t *signature, 
                                 UInt16 signatureLen)
{
  OSStatus err;
  ....

  if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
    goto fail;
  if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;
  if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
    goto fail;
  ....

fail:
  SSLFreeBuffer(&signedHashes);
  SSLFreeBuffer(&hashCtx);
  return err;
}

Обратите внимание, что если проверить этот фрагмент кода с помощью PVS-Studio, то он выдаст то же самое предупреждение: V779 CWE-561 Unreachable code detected. It is possible that an error is present.

Из-за двойного goto так же, как и в предыдущем примере, часть кода является недостижимой. Даже если переменная err равна нулю, происходит переход к метке fail. Это приводит к тому, что проверка подписи не производится. Функция возвращает 0, который обозначает, что с подписью всё хорошо. Далее программа получает ключ с сервера, даже если с подписью есть проблемы. Этот ключ нужен для шифрования данных при передаче.

Как видите, здесь точно такая же потенциальная уязвимость на самом деле уже оказалась настоящей серьезной уязвимостью.

Вывод. В случае игры было понятно, что ошибка некритична с точки зрения безопасности, но так будет не всегда. Потому не гадайте, есть опасность или нет. Даже если ошибка не может стать уязвимостью, её исправление пойдёт на пользу приложению.

SAST: поиск уязвимостей и потенциальных уязвимостей

Принципы работы SAST-инструментов разделяются на два направления.

Первое направление — поиск известных уязвимостей. Анализаторы первого типа работают по принципу антивируса. Им известно, как выглядят фрагменты кода, содержащие известные уязвимости (CVE). Эти фрагменты они и ищут в коде проверяемых проектов. На практике всё сложней, но общая идея именно такая.

Анализаторы этого типа помогут выявить, например, что в вашем коде используется старая версия библиотеки, содержащая известную и давно найденную уязвимость. Инструменты, осуществляющие поиск по базе, практически не дают ложных срабатываний, но они бессильны, когда речь заходит о поиске ошибок в новом коде (уязвимостей нулевого дня).

Второе направление: поиск уязвимостей нулевого дня. Приложение может содержать ошибку, которая некоторое время будет оставаться незамеченной. Если хакер обнаружит такую ошибку и придумает, как её можно эксплуатировать, то она превратится в новую уязвимость.

Анализаторы второго типа помогают обнаруживать ошибки, которые потенциально могут стать причиной уязвимости. Большое количество таких паттернов ошибок собраны в CWE, и многие разработчики анализаторов ориентируются на эту базу.

Анализатор PVS-Studio является SAST решением именно этого типа и умеет классифицировать свои предупреждения согласно CWE. Другими словами, можно сказать, что PVS-Studio ориентирован на предотвращение уязвимостей нулевого дня.

Дополнительные ссылки

Популярные статьи по теме
C++ — язык 2022 года. Почему так, и что с другими языками?

Дата: 20 Янв 2023

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

C++ становится языком 2022 года по версии TIOBE, обгоняя Python. Rust, C#, Go и прочие — далеко позади. Странно? Сейчас разберёмся.
PVS-Studio в 2022 году

Дата: 19 Янв 2023

Автор: Полина Алексеева

На дворе январь 2023, а значит, самое время подвести итоги уже прошлого 2022 года. Мы расскажем, чем занимались, и покажем, что нового появилось в анализаторе за это время. Давайте вместе взглянем на…
PVS-Studio: 2 фишки для быстрого старта

Дата: 08 Дек 2022

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

В этой заметке расскажу, как легко начать использовать PVS-Studio. Рассмотрим два сценария: когда вы пробуете анализатор впервые и когда внедряете его в проект.
Почему ты делаешь за меня мою работу? Типы людей, которые не пишут в поддержку

Дата: 06 Дек 2022

Автор: Алёна Фоканова

Привлекательное название статьи должно раскрывать то, что будет в ней. Так вот, работа специалистом поддержки клиентов подразумевает появление вопросов к пользователю. Иногда возникает как раз такой:…
Как Apple и другие крупные компании настиг программный баг

Дата: 09 Ноя 2022

Автор: Ульяна Гришина

Сегодня мы отобрали свежие случаи программных ошибок, чтобы вы могли немного отвлечься и, возможно, узнать что-то новенькое. Если вам интересно узнать, как программисту удалось сломать Интернет по вс…

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

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