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

• Терминология
• Различие между потенциальной уязвимостью и уязвимостью
• Пример потенциальной уязвимости
• SAST: поиск уязвимостей и потенциальных уязвимостей
• Дополнительные ссылки

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

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

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

Потенциальная уязвимость. Ошибка в коде, которую теоретически можно использовать и создать эксплойт. Другие названия: дефект безопасности, 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 ориентирован на предотвращение уязвимостей нулевого дня.

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

• Статический анализатор кода PVS-Studio как защита от уязвимостей нулевого дня
• Как PVS-Studio может помочь в поиске уязвимостей?
• Технологии, используемые в анализаторе кода PVS-Studio для поиска ошибок и потенциальных уязвимостей
• Анализатор кода PVS-Studio как инструмент для поиска дефектов безопасности и защищённости приложений. Отчёт Forrester Research о SAST, Q3 2020
• Какая разница между DevOps и DevSecOps?
• OWASP, уязвимости и taint анализ в PVS-Studio C#

0

0

0

0

ПОДЕЛИТЬСЯ

Присылаем лучшие статьи раз в месяц