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

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

Потенциальная уязвимость (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 решили назвать серьёзные дефекты сразу уязвимостями.

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

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

Ошибка "недостижимый код" описана в базе 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-решения (Static Application Security Testing). Они выполняют статический анализ кода с целью поиска дефектов безопасности. Подобные инструменты ищут дефекты безопасности, описанные, например, CWE и OWASP Top 10.

Примером SAST-решения для поиска потенциальных уязвимостей является PVS-Studio.

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

Термины

• CWE (Common Weakness Enumeration)
• CVE (Common Vulnerabilities and Exposures)
• OWASP
• SAST (Static Application Security Testing)
• Уязвимость нулевого дня

Статьи

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

0

0

0

0

ПОДЕЛИТЬСЯ

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